Open MoJl4yH opened 2 years ago
Thanks @MoJl4yH, that is quite a strange one; it reduces to this:
% ./miniperl -we '\sort { 1 } "xx" .. 1'
Useless use of reference constructor in void context at -e line 1.
Argument "xx" isn't numeric in range (or flop) at -e line 1.
miniperl: inline.h:284: Perl_POPMARK: Assertion `(PL_markstack_ptr > PL_markstack) || !"MARK underflow"' failed.
Aborted (core dumped)
%
The segfault appears to be a bug introduced sometime between 5.24 and 5.28, ameliorated to an underflow panic since 5.34. I'll try to bisect.
Thanks @MoJl4yH, that is quite a strange one; it reduces to this:
% ./miniperl -we '\sort { 1 } "xx" .. 1' Useless use of reference constructor in void context at -e line 1. Argument "xx" isn't numeric in range (or flop) at -e line 1. miniperl: inline.h:284: Perl_POPMARK: Assertion `(PL_markstack_ptr > PL_markstack) || !"MARK underflow"' failed. Aborted (core dumped) %
The segfault appears to be a bug introduced sometime between 5.24 and 5.28, ameliorated to an underflow panic since 5.34. I'll try to bisect.
Also i found other crash, for example memory leak and about 30 crash with heap-buffer-overflow. I can collect it in archive and send on your e-mail.
The segfault appears to be a bug introduced sometime between 5.24 and 5.28, ameliorated to an underflow panic since 5.34. I'll try to bisect.
I misspoke: the difference between segfault and underflow is the difference between non-debugging and debugging perls.
The crash is introduced by b369834256:
commit b3698342565fb462291fba4b432cfcd05b6eb4e1
Author: Zefram <zefram@fysh.org>
Date: Fri Jan 27 03:55:46 2017 +0000
fix range op under aborted constant folding
When constant-folding a range/flipflop construct, the op_next threading
of peephole optimisation caused multiple ops in the construct to have
a null op_next, because the final (and top-level) op in the construct
is a null op. This meant that simple restoration of the top-level
op's op_next after execution wouldn't get it back into a fit state
to be composed with other ops. In the event that the range construct
couldn't be constant-folded this made it compile to a broken optree.
If it couldn't be constant-folded but could actually be executed, for
example because it generated a warning, this meant the brokenness would
be encountered at runtime. Execution would stop after the range op,
because of the null op_next.
To avoid this, temporarily mark the null op as a custom op during the
peephole optimisation that supports the execution for constant-folding.
This prevents it being op_next-threaded out, so simple op_next restoring
then works. If the constant-folding is aborted, it compiles to an
operational optree. However, the suppression of duplicate peephole
optimisation means that the null op is never ultimately threaded out
as it should be. For the time being, this stands as a cost of failed
constant-folding of range constructs.
Fixes [perl #130639].
(That was #15832.)
@iabyn that last paragraph is curious, could this also trip over the changes you made to the handling of null ops?
I hope someone more familiar with optrees than I can analyse this further.
Also i found other crash, for example memory leak and about 30 crash with heap-buffer-overflow. I can collect it in archive and send on your e-mail.
Sure if you like, you'll find my email in AUTHORS if you need it.
Please consider minimizing the test cases first. Either afl-cmin
or afl-tmin
will try to do that for you (I forget the difference between them), but you'll need to verify that the reduced versions still fail in the same way.
Hugo van der Sanden
$ ./perl -Ds -we '\sort { 1 } "xx" .. 1'
=> *
=> *
=> * PV("xx"\0)
=> * PV("xx"\0)
=> * PV("xx"\0) IV(1)
Useless use of reference constructor in void context at -e line 1.
EXECUTING...
=>
=>
=>
=> *
=> **
=> **
=> ** PVNV("xx"\0)
=> ** PVNV("xx"\0)
=> ** PVNV("xx"\0) IV(1)
Argument "xx" isn't numeric in range (or flop) at -e line 1.
=> ** IV(0) IV(1)
=> ** IV(0) IV(1)
=>
=>
=> PVNV("xx"\0)
=> PVNV("xx"\0)
=> PVNV("xx"\0) IV(1)
=> IV(0) IV(1)
=> IV(0) IV(1)
=>
=>
=> PVNV("xx"\0)
=> PVNV("xx"\0)
=> PVNV("xx"\0) IV(1)
=> IV(0) IV(1)
=> IV(0) IV(1)
perl: inline.h:379: Perl_POPMARK: Assertion `(PL_markstack_ptr > PL_markstack) || !"MARK underflow"' failed.
Aborted
This looks like a loop to me. Somehow "xx"
and 1
are getting pushed on the stack (and turned into 0 1
) repeatedly.
Description
i'm used afl-fuzz for find bug in interpreter perl. And the fuzzer finds a line that results in "heap-buffer-overflow".
For proofs i build perl with this command
And i feed the found string to the input of the perl.
Steps to Reproduce
just pass this segfauit.zip as input.
Expected behavior
Also, if i will use old version perl (from repo ubuntu), i get "Segmentation fault"
Perl configuration
I found about 700 crashes and I'm trying to prove them. i can upload it here, and we try to prove exploitability.