From geeknik@protonmail.ch

While testing Perl v5.29.4-32-gf196658042, I discovered that ./perl -e '\grep% N&ep%\&hN,@​N=hhN,*N=hNN&ep%\&hN,@​N=hhN,,K' causes a segfault triggered by an invalid read as seen by the following stack trace​:

Operator or semicolon missing before &ep at -e line 1.
Ambiguous use of & resolved as operator & at -e line 1.
Operator or semicolon missing before &ep at -e line 1.
Ambiguous use of & resolved as operator & at -e line 1.
UndefinedBehaviorSanitizer​:DEADLYSIGNAL
==18963==ERROR​: UndefinedBehaviorSanitizer​: SEGV on unknown address 0x00ff00000012 (pc 0x00000069b85a bp 0x7fff7820f330 sp 0x7fff7820f300 T18963)
==18963==The signal is caused by a READ memory access.
  #0 0x69b859 in S_mg_findext_flags /root/perl/mg.c​:412​:2
  #1 0x6e5700 in Perl_hv_placeholders_get /root/perl/hv.c​:3183​:24
  #2 0x711efe in S_padhv_rv2hv_common /root/perl/pp_hot.c​:1812​:13
  #3 0x71299e in Perl_pp_rv2av /root/perl/pp_hot.c​:2004​:16
  #4 0x67d9d8 in Perl_runops_debug /root/perl/dump.c​:2536​:23
  #5 0x4b18ae in S_run_body /root/perl/perl.c
  #6 0x4b17da in perl_run /root/perl/perl.c​:2611​:2
  #7 0x4461b9 in main /root/perl/perlmain.c​:122​:9
  #8 0x7f8fcfc932e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
  #9 0x426889 in _start (/root/perl/perl+0x426889)

UndefinedBehaviorSanitizer can not provide additional info.
==18963==ABORTING

From @jkeenan

On Mon, 05 Nov 2018 14​:41​:32 GMT, geeknik@​protonmail.ch wrote​:

While testing Perl v5.29.4-32-gf196658042, I discovered that ./perl -e
'\grep% N&ep%\&hN,@​N=hhN,*N=hNN&ep%\&hN,@​N=hhN,,K' causes a segfault
triggered by an invalid read as seen by the following stack trace​:

Operator or semicolon missing before &ep at -e line 1.
Ambiguous use of & resolved as operator & at -e line 1.
Operator or semicolon missing before &ep at -e line 1.
Ambiguous use of & resolved as operator & at -e line 1.
UndefinedBehaviorSanitizer​:DEADLYSIGNAL
==18963==ERROR​: UndefinedBehaviorSanitizer​: SEGV on unknown address
0x00ff00000012 (pc 0x00000069b85a bp 0x7fff7820f330 sp 0x7fff7820f300
T18963)
==18963==The signal is caused by a READ memory access.
#0 0x69b859 in S_mg_findext_flags /root/perl/mg.c​:412​:2
#1 0x6e5700 in Perl_hv_placeholders_get /root/perl/hv.c​:3183​:24
#2 0x711efe in S_padhv_rv2hv_common /root/perl/pp_hot.c​:1812​:13
#3 0x71299e in Perl_pp_rv2av /root/perl/pp_hot.c​:2004​:16
#4 0x67d9d8 in Perl_runops_debug /root/perl/dump.c​:2536​:23
#5 0x4b18ae in S_run_body /root/perl/perl.c
#6 0x4b17da in perl_run /root/perl/perl.c​:2611​:2
#7 0x4461b9 in main /root/perl/perlmain.c​:122​:9
#8 0x7f8fcfc932e0 in __libc_start_main (/lib/x86_64-linux-
gnu/libc.so.6+0x202e0)
#9 0x426889 in _start (/root/perl/perl+0x426889)

UndefinedBehaviorSanitizer can not provide additional info.
==18963==ABORTING

This code has thrown warnings since at least perl-5.8.4.

#####
$ perlbrew use perl-5.8.4
$ perl -we '\grep% N&ep%\&hN,@​N=hhN,*N=hNN&ep%\&hN,@​N=hhN,,K'
Unquoted string "ep" may clash with future reserved word at -e line 1.
Operator or semicolon missing before &ep at -e line 1.
Ambiguous use of & resolved as operator & at -e line 1.
Unquoted string "ep" may clash with future reserved word at -e line 1.
Operator or semicolon missing before &ep at -e line 1.
Ambiguous use of & resolved as operator & at -e line 1.
Useless use of reference constructor in void context at -e line 1.
Argument "ep" isn't numeric in modulus (%) at -e line 1.
Argument "hNN" isn't numeric in bitwise and (&) at -e line 1.
Argument "ep" isn't numeric in modulus (%) at -e line 1.
#####

But it only resulted in a segfault starting in January 2012.

#####
$ perl Porting/bisect.pl --start=v5.14.4 --end=v5.16.3 --crash -- ./perl -Ilib -e '\grep% N&ep%\&hN,@​N=hhN,*N=hNN&ep%\&hN,@​N=hhN,,K'

60edcf0 is the first bad commit
commit 60edcf0
Author​: Father Chrysostomos <sprout@​cpan.org>
Date​: Mon Jan 9 19​:54​:26 2012 -0800

  Better fix for perl #107440
 
  > > Actually, the simplest solution seem to be to put the av or hv on
  > > the mortals stack in pp_aassign and pp_undef, rather than in
  > > [ah]v_undef/clear.
  >
  > This makes me nervous. The tmps stack is typically cleared only on
  > statement boundaries, so we run the risks of
  >
  > * user-visible delaying of freeing elements;
  > * large tmps stack growth might be possible with
  > certain types of loop that repeatedly assign to an array without
  > freeing tmps (eg map? I think I fixed most map/grep tmps leakage
  > a
  > while back, but there may still be some edge cases).
  >
  > Surely an ENTER/SAVEFREESV/LEAVE inside pp_aassign is just as
  > efficient,
  > without any attendant risks?
  >
  > Also, although pp_aassign and pp_undef are now fixed, the
  > [ah]v_undef/clear functions aren't, and they're part of the public API
  > that can be called independently of pp_aassign etc. Ideally they
  > should
  > be fixed (so they don't crash in mid-loop), and their documentation
  > updated to point out that on return, their AV/HV arg may have been
  > freed.
 
  This commit takes care of the first part; it changes pp_aassign to use
  ENTER/SAVEFREESV/LEAVE and adds the same to h_freeentries (called both
  by hv_undef and hv_clear), av_undef and av_clear.
 
  It effectively reverts the C code part of 9f71cfe.

:100644 100644 1671f16e401e21dce7ab7fd8c22188ee6cfb2a9d 472600b6f0ab2953d43d2d2a01b94a0695aaf282 M av.c
:100644 100644 af41de86917e0f097570da1dc2636a008aa888f2 2cfe25bb4db28d1a7c37d5e27cde2854f6696375 M hv.c
:100644 100644 5910e8691d1e3fd7af919b158f61755b13136f38 eaf6a85277d68172b23deb48a8491f800564e9eb M pp.c
:100644 100644 add940049bec699a5075feb1138c2eee0a74e3e3 ff834a924e8e2cb248bc2bbd36be15ccc4e40c4f M pp_hot.c

Thank you very much.
--
James E Keenan (jkeenan@​cpan.org)

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

From @tonycoz

On Mon, 05 Nov 2018 06​:41​:32 -0800, geeknik@​protonmail.ch wrote​:

While testing Perl v5.29.4-32-gf196658042, I discovered that ./perl -e
'\grep% N&ep%\&hN,@​N=hhN,*N=hNN&ep%\&hN,@​N=hhN,,K' causes a segfault
triggered by an invalid read as seen by the following stack trace​:

Going by the code I suspect it's a stack-not-refcounted bug.

@​N is pushed, *N is modified (freeing the old @​N), access to now invalid SV formerly known as @​N.

Tony