Open p5pRT opened 6 years ago
Reply-To: jeremy@feusi.co
This is a bug report for perl from jeremy@feusi.co\, generated with the help of perlbug 1.40 running under perl 5.26.1.
-----------------------------------------------------------------
Perl segfaults when executing the attached program (perl \
Detailed backtrace:
==9327==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000000c (pc 0x00000084e5f2 bp 0x7ffeed336030 sp 0x7ffeed335a40 T0) ==9327==The signal is caused by a READ memory access. ==9327==Hint: address points to the zero page. #0 0x84e5f1 in Perl_pp_multiconcat /home/jfe/perl52/pp_hot.c #1 0x8488be in Perl_runops_standard /home/jfe/perl52/run.c:41:26 #2 0xa95bf6 in S_regmatch /home/jfe/perl52/regexec.c:7424:3 #3 0xa74ea0 in S_regtry /home/jfe/perl52/regexec.c:4086:14 #4 0xa57204 in Perl_regexec_flags /home/jfe/perl52/regexec.c:3943:7 #5 0x877ab1 in Perl_pp_subst /home/jfe/perl52/pp_hot.c:4212:10 #6 0x8488be in Perl_runops_standard /home/jfe/perl52/run.c:41:26 #7 0x5dbc91 in S_run_body /home/jfe/perl52/perl.c #8 0x5dabb4 in perl_run /home/jfe/perl52/perl.c:2646:2 #9 0x52f0b8 in main /home/jfe/perl52/perlmain.c:122:9 #10 0x7fe328886f29 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20f29) #11 0x43f999 in _start (/home/jfe/perl52/perl+0x43f999)
AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /home/jfe/perl52/pp_hot.c in Perl_pp_multiconcat ==9327==ABORTING
This bug was found with honggfuzz and asan.
#!./perl m/(?{print \<\<EOF A$A EOF })/g; eval 's/${\%A}{3}//e';
Looks like this has been fixed:
This is perl 5, version 30, subversion 0 (v5.30.0) built for MSWin32-x64-multi-thread
C:\fldr>perl fzz.pl
A
A
A
This is perl 5, version 28, subversion 1 (v5.28.1) built for x86_64-linux-gnu-thread-multi
me@disbox:~# perl fzz.pl
A
A
A
Ran out of time to dig deeper or bisect. Can do so at the weekend, unless someone wants to beat me to it.
Looks like it was fixed by 4e521aaf3ed717774455b3906bd5aa46bc397319
commit 4e521aaf3ed717774455b3906bd5aa46bc397319
Author: David Mitchell <davem@iabyn.com>
Date: Tue Feb 5 13:48:21 2019 +0000
Avoid leak in multiconcat with overloading.
RT #133789
In the path taken through pp_multiconcat() when one or more args have
side-effects such tieing or overloading, multiconcat has to decide
whether to just return the result of all the concatting as-is, or to
first assign it to an expression or variable if the op includes an
implicit assign (such as $lex = x.y.z or $a[0] = x.y.z).
The code was getting this right for those two cases, and was also
getting it right for the append cases ($lex .= x.y.z and $a[0] .= x.y.z),
which don't need assigns. But for the bare case (x.y.z) it was assigning
to the op's targ as well as returning the value. Hence leaking a
reference until destruction of the sub and its pad.
This commit stops the assign in that last case.
the first release for 4e521aaf3ed717774455b3906bd5aa46bc397319 is v5.29.8
On Thu, Oct 24, 2019 at 04:53:11PM -0700, Richard Leach wrote:
Looks like this has been fixed:
This is perl 5, version 30, subversion 0 (v5.30.0) built for MSWin32-x64-multi-thread C:\fldr>perl fzz.pl A A A
This is perl 5, version 28, subversion 1 (v5.28.1) built for x86_64-linux-gnu-thread-multi me@disbox:~# perl fzz.pl A A A
Ran out of time to dig deeper or bisect. Can do so at the weekend, unless someone wants to beat me to it.
It's not fixed, but its only an issue on non-threaded builds. The bug can be exhibited without using multiconcat, e.g.
my $A= "";
"" =~ m/(?{ my $x; })/;
my $s;
sub f { $s =~ s//foo/ }
f();
It's because the empty pattern in the s/// causes the last successful pattern to be used instead, which is the earlier m//. This is called with PL_curcop still pointing to f's pad, so the lookup of $x in the current pad retrieves a random pointer value off the end of f's pad.
It's basically a problem with the empty pattern misfeature . Needs fixing at some point.
-- 31 Dec 1661: "I have newly taken a solemne oath about abstaining from plays". 1 Jan 1662: "And after ... we went by coach to the play". -- The Diary of Samuel Pepys
Migrated from rt.perl.org#132991 (status was 'new')
Searchable as RT132991$