PERL-5.26.1 heap_use_after_free WRITE of size 1

[p5pRT]

Migrated from rt.perl.org#132618 (status was 'open')

Searchable as RT132618$

[p5pRT]

From sraums2498@gmail.com

=================================================================
==51675==ERROR​: AddressSanitizer​: heap-use-after-free on address 0x60300000e710 at pc 0x7f52377bae62 bp 0x7ffd5eb1b1f0 sp 0x7ffd5eb1a998
WRITE of size 1 at 0x60300000e710 thread T0
  #0 0x7f52377bae61 in __asan_memmove (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x8ce61)
  #1 0x1deaa24 in memmove /usr/include/x86_64-linux-gnu/bits/string3.h​:59
  #2 0x1deaa24 in Perl_sv_2pv_flags /home/asan_perl/Documents/perl-5.26.1/sv.c​:3092
  #3 0x2f6f182 in Perl_pp_pack /home/asan_perl/Documents/perl-5.26.1/pp_pack.c​:3128
  #4 0x1b1bc2e in Perl_runops_standard /home/asan_perl/Documents/perl-5.26.1/run.c​:41
  #5 0x9218a5 in S_run_body /home/asan_perl/Documents/perl-5.26.1/perl.c​:2519
  #6 0x9218a5 in perl_run /home/asan_perl/Documents/perl-5.26.1/perl.c​:2447
  #7 0x46b6a7 in main /home/asan_perl/Documents/perl-5.26.1/perlmain.c​:123
  #8 0x7f5236a2282f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
  #9 0x46c888 in _start (/home/asan_perl/Documents/perl-5.26.1/perl+0x46c888)

0x60300000e710 is located 0 bytes inside of 32-byte region [0x60300000e710,0x60300000e730)
freed by thread T0 here​:
  #0 0x7f52377c62ca in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x982ca)
  #1 0x1cd1d7d in Perl_sv_clear /home/asan_perl/Documents/perl-5.26.1/sv.c​:6827
  #2 0x1ca0107 in Perl_sv_free2 /home/asan_perl/Documents/perl-5.26.1/sv.c​:7073
  #3 0x2277eb3 in S_SvREFCNT_dec_NN /home/asan_perl/Documents/perl-5.26.1/inline.h​:200
  #4 0x2277eb3 in Perl_free_tmps /home/asan_perl/Documents/perl-5.26.1/scope.c​:212
  #5 0x90bc4c in S_parse_body /home/asan_perl/Documents/perl-5.26.1/perl.c​:2397
  #6 0x90bc4c in perl_parse /home/asan_perl/Documents/perl-5.26.1/perl.c​:1692
  #7 0x46b239 in main /home/asan_perl/Documents/perl-5.26.1/perlmain.c​:121
  #8 0x7f5236a2282f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

previously allocated by thread T0 here​:
  #0 0x7f52377c6602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
  #1 0x167dd81 in Perl_safesysmalloc /home/asan_perl/Documents/perl-5.26.1/util.c​:153
  #2 0x1adf2d0 in Perl_av_extend_guts /home/asan_perl/Documents/perl-5.26.1/av.c​:186
  #3 0x1aed221 in Perl_av_extend /home/asan_perl/Documents/perl-5.26.1/av.c​:80
  #4 0x1aed221 in Perl_av_store /home/asan_perl/Documents/perl-5.26.1/av.c​:355
  #5 0x186239e in S_mro_get_linear_isa_dfs /home/asan_perl/Documents/perl-5.26.1/mro_core.c​:260
  #6 0x1870900 in Perl_mro_get_linear_isa /home/asan_perl/Documents/perl-5.26.1/mro_core.c​:413
  #7 0x1892bab in Perl_mro_isa_changed_in /home/asan_perl/Documents/perl-5.26.1/mro_core.c​:652
  #8 0x178f953 in Perl_magic_clearisa /home/asan_perl/Documents/perl-5.26.1/mg.c​:1728
  #9 0x178f953 in Perl_magic_setisa /home/asan_perl/Documents/perl-5.26.1/mg.c​:1688
  #10 0x174ef47 in Perl_mg_set /home/asan_perl/Documents/perl-5.26.1/mg.c​:296
  #11 0x1aed853 in Perl_av_store /home/asan_perl/Documents/perl-5.26.1/av.c​:384
  #12 0x8b561b in Perl_populate_isa /home/asan_perl/Documents/perl-5.26.1/perl.c​:4222
  #13 0x90600a in S_init_predump_symbols /home/asan_perl/Documents/perl-5.26.1/perl.c​:4252
  #14 0x90600a in S_parse_body /home/asan_perl/Documents/perl-5.26.1/perl.c​:2297
  #15 0x90600a in perl_parse /home/asan_perl/Documents/perl-5.26.1/perl.c​:1692
  #16 0x46b239 in main /home/asan_perl/Documents/perl-5.26.1/perlmain.c​:121
  #17 0x7f5236a2282f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

SUMMARY​: AddressSanitizer​: heap-use-after-free ??​:0 __asan_memmove
Shadow bytes around the buggy address​:
  0x0c067fff9c90​: 07 fa fa fa 00 00 01 fa fa fa 00 00 05 fa fa fa
  0x0c067fff9ca0​: 00 00 00 04 fa fa 00 00 01 fa fa fa 00 00 01 fa
  0x0c067fff9cb0​: fa fa 00 00 06 fa fa fa 00 00 05 fa fa fa 00 00
  0x0c067fff9cc0​: 02 fa fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa
  0x0c067fff9cd0​: 00 00 00 00 fa fa fd fd fd fd fa fa 00 00 00 00
=>0x0c067fff9ce0​: fa fa[fd]fd fd fd fa fa 00 00 00 00 fa fa fd fd
  0x0c067fff9cf0​: fd fd fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa
  0x0c067fff9d00​: fd fd fd fd fa fa fd fd fd fd fa fa 00 00 00 00
  0x0c067fff9d10​: fa fa 00 00 00 00 fa fa fd fd fd fd fa fa 00 00
  0x0c067fff9d20​: 00 fa fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa
  0x0c067fff9d30​: 00 00 00 05 fa fa 00 00 00 00 fa fa fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes)​:
  Addressable​: 00
  Partially addressable​: 01 02 03 04 05 06 07
  Heap left redzone​: fa
  Heap right redzone​: fb
  Freed heap region​: fd
  Stack left redzone​: f1
  Stack mid redzone​: f2
  Stack right redzone​: f3
  Stack partial redzone​: f4
  Stack after return​: f5
  Stack use after scope​: f8
  Global redzone​: f9
  Global init order​: f6
  Poisoned by user​: f7
  Container overflow​: fc
  Array cookie​: ac
  Intra object redzone​: bb
  ASan internal​: fe
==51675==ABORTING

--
Regards,
SRAUMS

[p5pRT]

From sraums2498@gmail.com

138

[p5pRT]

From @hvds

I get a different stack trace (same with blead or 5.26.1), which reduces to this and looks very like a stack refcounting issue​:
% ./miniperl -e '$$W += $W = 0'
ASAN​:SIGSEGV

==15388==ERROR​: AddressSanitizer​: SEGV on unknown address 0x000000000000 (pc 0x000000d82176 sp 0x7fff60547580 bp 0x7fff60547830 T0)
  #0 0xd82175 in Perl_sv_setiv /src/package/lang/perl/gitperl/sv.c​:1662
  #1 0xd8413b in Perl_sv_setuv /src/package/lang/perl/gitperl/sv.c​:1709
  #2 0xd84522 in Perl_sv_setuv_mg /src/package/lang/perl/gitperl/sv.c​:1730
  #3 0xcff905 in Perl_pp_add /src/package/lang/perl/gitperl/pp_hot.c​:1612
  #4 0xcd10f7 in Perl_runops_standard /src/package/lang/perl/gitperl/run.c​:41
  #5 0x644229 in S_run_body /src/package/lang/perl/gitperl/perl.c​:2730
  #6 0x6421b6 in perl_run /src/package/lang/perl/gitperl/perl.c​:2646
  #7 0x14aa7c8 in main /src/package/lang/perl/gitperl/miniperlmain.c​:128
  #8 0x7fcd15454f44 (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
  #9 0x49947c in _start (/src/package/lang/perl/gitperl/miniperl+0x49947c)

AddressSanitizer can not provide additional info.
SUMMARY​: AddressSanitizer​: SEGV /src/package/lang/perl/gitperl/sv.c​:1662 Perl_sv_setiv
==15388==ABORTING
%

I'm not sure what in the original test case allowed the OP's invocation to get as far as pp_pack​: I guess the additional assignments between the two uses of $W managed to reuse the freed SV and set it to something valid enough to let it to get further.

Hugo

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @tonycoz

On Sun, 07 Jan 2018 04​:20​:15 -0800, hv wrote​:

I get a different stack trace (same with blead or 5.26.1), which
reduces to this and looks very like a stack refcounting issue​:
% ./miniperl -e '$$W += $W = 0'
ASAN​:SIGSEGV

==15388==ERROR​: AddressSanitizer​: SEGV on unknown address
0x000000000000 (pc 0x000000d82176 sp 0x7fff60547580 bp 0x7fff60547830
T0)
#0 0xd82175 in Perl_sv_setiv
/src/package/lang/perl/gitperl/sv.c​:1662
#1 0xd8413b in Perl_sv_setuv
/src/package/lang/perl/gitperl/sv.c​:1709
#2 0xd84522 in Perl_sv_setuv_mg
/src/package/lang/perl/gitperl/sv.c​:1730
#3 0xcff905 in Perl_pp_add
/src/package/lang/perl/gitperl/pp_hot.c​:1612
#4 0xcd10f7 in Perl_runops_standard
/src/package/lang/perl/gitperl/run.c​:41
#5 0x644229 in S_run_body
/src/package/lang/perl/gitperl/perl.c​:2730
#6 0x6421b6 in perl_run /src/package/lang/perl/gitperl/perl.c​:2646
#7 0x14aa7c8 in main
/src/package/lang/perl/gitperl/miniperlmain.c​:128
#8 0x7fcd15454f44 (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#9 0x49947c in _start
(/src/package/lang/perl/gitperl/miniperl+0x49947c)

AddressSanitizer can not provide additional info.
SUMMARY​: AddressSanitizer​: SEGV
/src/package/lang/perl/gitperl/sv.c​:1662 Perl_sv_setiv
==15388==ABORTING
%

Yes, it's a stack not refcounted issue.

The $$W is executed first, which since it's executed in lvalue context, auto-vivifies the value of $W into reference to an anonymous scalar, and that anonymous scalar is pushed onto the stack.

Then the $W = 0 is executed, releasing the refercence above, releasing the anonymous scalar.

Finally the assignment to that anonymous scalar is attempted and Bad Things Happen.

I've moved it to the public queue and linked it to the meta ticket.

I'm not sure what in the original test case allowed the OP's
invocation to get as far as pp_pack​: I guess the additional
assignments between the two uses of $W managed to reuse the freed SV
and set it to something valid enough to let it to get further.

That seems likely.

Tony