Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PERL-5.26.1 heap_use_after_free WRITE of size 1 #16323

Open
p5pRT opened this issue Dec 20, 2017 · 5 comments
Open

PERL-5.26.1 heap_use_after_free WRITE of size 1 #16323

p5pRT opened this issue Dec 20, 2017 · 5 comments

Comments

@p5pRT
Copy link

@p5pRT p5pRT commented Dec 20, 2017

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

Searchable as RT132618$

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 20, 2017

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
Copy link
Author

@p5pRT p5pRT commented Dec 20, 2017

From sraums2498@gmail.com

138

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 7, 2018

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
Copy link
Author

@p5pRT p5pRT commented Jan 7, 2018

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 31, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants