-
Notifications
You must be signed in to change notification settings - Fork 540
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
31 byte one liner crashes Perl5.21.9 #14447
Comments
From @geeknikGood morning. The fuzzing attack against Perl continues with an interesting /home/geeknik/perl5/perl -v Using the american fuzzy lop (http://http://lcamtuf.coredump.cx/afl/) CC=/path/to/afl-gcc ./Configure (defaulted through all of the options) Test case and core dump are attached. valgrind -q /home/geeknik/perl5/perl final-crasher4 gdb /home/geeknik/perl5/perl core warning: Can't read pathname for load map: Input/output error. Test case: hexdump: |
From @geeknikA slightly different test case (30 bytes) provides a vastly different gdb perl -e 's)$0{0h());qx(@0);qx(@0);qx[-]' (Core was generated by `perl -e s)$0{0h());qx(@0);qx(@0);qx[-]'. Bareword found where operator expected at -e line 1, near "0h" |
From @geeknikOn Mon Jan 26 03:40:33 2015, brian.carpenter@gmail.com wrote:
Crashes Perl 5.21.7 (v5.21-6-602-ge9d2bd8))
Does not crash Perl 5.21.7 |
From @geeknikThis crash is still present in v5.21.9 (v5.21.8-200-ga57d3d4). |
From @cpansproutOn Mon Jan 26 03:40:33 2015, brian.carpenter@gmail.com wrote:
Yes, very interesting.
This is a case where a syntax error causes scopes to be popped when the lexing state is LEX_KNOWNEXT, and it changes to LEX_NORMAL, somehow corrupting the pending token stack. I suspect the fix will be to eliminate the LEX_KNOWNEXT state and check the number of items on the pending token stack instead. -- Father Chrysostomos |
The RT System itself - Status changed from 'new' to 'open' |
From @wolfsageOn Sat Feb 07 17:39:18 2015, sprout wrote:
For what it's worth, I bisected this test case to: eae48c8 is the first bad commit which is what the '$1=eval{a:}' case bisected to - https://rt-archive.perl.org/perl5/Ticket/Display.html?id=123652. The bisect was... mhorsfall@dory:~/p5/perl$ cat ~/runner mhorfall@dory:~/p5/perl$ /home/mhorsfall/perl-1/Porting/bisect.pl --start=v5.13.6 --end=v5.13.7 -j 8 -- ./perl -Ilib /home/mhorsfall/runner I had to hack /home/mhorsfall/perl-1/Porting/bisect-runner.pl to comment out: I can't get this bug to trigger if I compile with -D optimize=-g. It triggers with ./Configure -des -Dusedevel though. Also, I can't trigger it with threads: ./Configure -des -Dusedevel -Dusethreads -- Matthew Horsfall (alh) |
From @cpansproutOn Sun Feb 08 12:54:38 2015, alh wrote:
Even if it doesn’t crash, the -DT output gets scrambled with lines like: ### 1:LEX_KNOWNEXT/XTERM "@0" What happens if you bisect with -DT and check for ‘<== ??’ in the output? -- Father Chrysostomos |
From @cpansproutOK, I’ve now fixed this one in 7aa8cb0. -- Father Chrysostomos |
@cpansprout - Status changed from 'open' to 'pending release' |
From @wolfsageOn Sun, Feb 8, 2015 at 5:56 PM, Father Chrysostomos via RT
More fun here. I had to compile all versions with -O2 -g to get this mhorsfall@dory:~/perl-1$ git show f05d700 Prevent the tokenizer from segfaulting in debug mode when a FUNC p4raw-id: //depot/perl@33833 diff --git a/toke.c b/toke.c Attached are the -DT output from before the commit and after the -- Matthew Horsfall (alh) |
From @wolfsage### 0:LEX_NORMAL/XSTATE "\n;" ### 1:LEX_INTERPPUSH/XTERM ";qx(@0);qx(@0);qx[-]\n" ### 1:LEX_INTERPCONCAT/XTERM "$0{0h(" ### 1:LEX_INTERPENDMAYBE/XOPERATOR "{0h(" ### 1:LEX_INTERPENDMAYBE/XOPERATOR "{0h(" ### 1:LEX_INTERPNORMAL/XSTATE "0h(" ### 1:LEX_INTERPNORMAL/XOPERATOR "h(" ### <== '&' ### 1:LEX_NORMAL/XOPERATOR ";qx(@0);qx(@0);qx[-]\n" ### 1:LEX_NORMAL/XSTATE "qx(@0);qx(@0);qx[-]\n" ### 1:LEX_INTERPPUSH/XTERM ";qx(@0);qx[-]\n" ### 1:LEX_INTERPCONCAT/XTERM "@0" ### forced token: ### forced token: ### forced token: ### forced token: |
From @wolfsage### 0:LEX_NORMAL/XSTATE "\n;" ### 1:LEX_INTERPPUSH/XTERM ";qx(@0);qx(@0);qx[-]\n" ### 1:LEX_INTERPCONCAT/XTERM "$0{0h(" ### 1:LEX_INTERPENDMAYBE/XOPERATOR "{0h(" ### 1:LEX_INTERPENDMAYBE/XOPERATOR "{0h(" ### 1:LEX_INTERPNORMAL/XSTATE "0h(" ### 1:LEX_INTERPNORMAL/XOPERATOR "h(" ### <== '&' ### 1:LEX_NORMAL/XOPERATOR ";qx(@0);qx(@0);qx[-]\n" ### 1:LEX_NORMAL/XSTATE "qx(@0);qx(@0);qx[-]\n" ### 1:LEX_INTERPPUSH/XTERM ";qx(@0);qx[-]\n" ### 1:LEX_INTERPCONCAT/XTERM "@0" ### forced token: ### forced token: ### forced token: ### forced token: ### 1:LEX_KNOWNEXT/XTERM "@0" ### 1:LEX_NORMAL/XTERM ";qx(@0);qx[-]\n" ### 1:LEX_NORMAL/XSTATE "qx(@0);qx[-]\n" ### 1:LEX_INTERPPUSH/XTERM ";qx[-]\n" ### 1:LEX_INTERPCONCAT/XTERM "@0" ### forced token: ### forced token: ### forced token: ### forced token: ### 1:LEX_KNOWNEXT/XTERM "@0" ### 1:LEX_KNOWNEXT/XTERM "@0" ### 1:LEX_NORMAL/XTERM ";qx[-]\n" ### 1:LEX_NORMAL/XSTATE "qx[-]\n" ### 1:LEX_INTERPPUSH/XTERM "\n" ### 1:LEX_INTERPCONCAT/XTERM "-" ### 1:LEX_KNOWNEXT/XTERM "" ### 1:LEX_KNOWNEXT/XTERM "" syntax error at -e line 1, near "0h" |
From @cpansproutOn Mon Feb 09 07:08:38 2015, alh wrote:
Well, it is certainly interesting. The first one stops abruptly at the buffer overflow. Presumably it crashed because of the bug that 05d7009fff fixed. The second one shows definitely buggy output. When the overflow happens, nextval overflows into nexttype and nexttype overflows into nexttoke. Since nexttoke is an offset into the nexttype and nextval arrays, it is possible to read ahead into save_curcop, which is a memory address. That would explain why the bug is intermittent. I suspect this bug is *old* and predates -DT output. -- Father Chrysostomos |
From @wolfsageOn Mon, Feb 9, 2015 at 12:34 PM, Father Chrysostomos via RT
Yeah. Thanks for the explanations. I'm done digging I think :) -- Matthew Horsfall (alh) |
From @khwilliamsonThanks for submitting this ticket The issue should be resolved with the release today of Perl v5.22, available at http://www.perl.org/get.html -- |
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#123677 (status was 'resolved')
Searchable as RT123677$
The text was updated successfully, but these errors were encountered: