Segmentation fault in Perl5 while fuzzing Perl binary (possible stack overflow?) #14391
Comments
From @geeknikI'm still fuzzing a Perl binary that I built from git source on 01/02/2015 CC=/path/to/afl-gcc ./Configure This is perl 5, version 21, subversion 8 (v5.21.8 (v5.21.7-209-g4e27940)) Besides the above information, this version of Perl was compiled using all While fuzzing the perl binary, I found another testcase which causes a geeknik@deb7fuzz:~/findings/perl/fuzzer02/crashes$ /home/geeknik/perl5/perl String found where operator expected at geeknik@deb7fuzz:~/findings/perl/fuzzer02/crashes$ valgrind -q String found where operator expected at geeknik@deb7fuzz:~/findings/perl/fuzzer02/crashes$ gdb GNU gdb (GDB) 7.4.1-debian This is free software: you are free to change and redistribute it. warning: Can't read pathname for load map: Input/output error. ./perlbug -d Flags: This perlbug was built using Perl 5.21.8 - Fri Jan 2 19:02:59 CST 2015 Site configuration information for perl 5.21.7: Configured by geeknik at Thu Dec 18 14:34:01 CST 2014. Summary of my perl5 (revision 5 version 21 subversion 7) configuration: @INC for perl 5.21.7: Environment for perl 5.21.7: Details on AFL can be found here: http://lcamtuf.coredump.cx/afl/ |
From @jkeenanThe patch provided by khw in RT #123539 to address a different segfault reported by the same tester does not address the problem in *this* ticket. So this is a different problem. ##### -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @tonycozOn Sun Jan 04 16:23:21 2015, jkeenan wrote:
Right, this is a problem with the construction of the op-tree. The loop: while (OpSIBLING(kid) != repl) attempts to deref a NULL kid because it can't find repl in the op's children. Adding NULL checks here crashes in op_free() instead. I'm working on producing a smaller test-case. Tony |
From @tonycozOn Sun Jan 04 18:21:03 2015, tonyc wrote:
Attached a smaller test case. Tony |
From @cpansproutOn Sun Jan 04 18:21:03 2015, tonyc wrote:
I cannot reproduce this on a Mac. I do get a crash on dromedary, but no debugging symbols, which makes it a little hard to debug. :-( This has to be some sort of memory corruption if op_last points to something not found in the op_first->op_sibling->... chain. -- Father Chrysostomos |
From @cpansproutOn Sun Jan 04 23:41:14 2015, sprout wrote:
A bisect blames it on me: 8be227a is the first bad commit CV-based slab allocation for ops -- Father Chrysostomos |
From @andkIn case you still need a stacktrace, I have produced one with Program terminated with signal SIGABRT, Aborted. -- |
From @cpansproutOn Sun Jan 04 18:21:03 2015, tonyc wrote:
In this case kid and repl are the op_first and op_last, respectively, of expr. But expr is an unop with no op_last field. So cLISTOPx(...)->op_last reads past the end of the op struct into the next op slot, and repl ends up holding an opslot pointer. That can’t be found in the kids (there is only one kid), so we crash when doing OpSIBLING(NULL), as you observed.
Because substrepl is pointing to something that is not an op.
I got it down to s/${<>{})//. On Mon Jan 05 06:05:53 2015, sprout wrote:
It started failing then because previously ops were allocated via calloc, so cLISTOPx(unop)->op_last would produce a null pointer. So kid->op_sibling == repl was true on the very first kid (the only kid), and the loop would end. I fixed this in 08b999a. -- Father Chrysostomos |
|
@cpansprout - Status changed from 'open' to 'pending release' |
From @cpansproutOn Thu Jan 08 18:12:29 2015, sprout wrote:
Actually, my reduced case *does* crash in 5.10-14, but not in 5.8[789]. -- Father Chrysostomos |
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#123542 (status was 'resolved')
Searchable as RT123542$
The text was updated successfully, but these errors were encountered: