Segmentation Fault in Perl 5.21.8 while fuzzing Perl binary #14389
Comments
From @geeknikI cloned the git repo on 01/02/2015 and built from source using the afl-gcc 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 new perl binary, I found a testcase that causes a @@ VALGRIND OUTPUT @@ valgrind -q /home/geeknik/perl5/perl @@ GDB OUTPUT @@ gdb /home/geeknik/perl5/perl core This is free software: you are free to change and redistribute it. warning: Can't read pathname for load map: Input/output error. geeknik@deb7fuzz:~/perl5/utils$ ./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: |
From @jkeenanOn Sat Jan 03 11:49:13 2015, brian.carpenter@gmail.com wrote:
Can you describe how one obtains the afl-gcc compiler?
I'm a bit puzzled about the test case, since, insofar as it is intended to be a perl program, it fails to compile. It reports a syntax error near 'printr)'. Can you clarify? Thank you very much. -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @maukeAm 03.01.2015 um 22:54 schrieb James E Keenan via RT:
http://lcamtuf.coredump.cx/afl/
As the original bug report says: syntax error at ./id:000000,sig:11,src:002461+016504,op:splice,rep:32 Perl panics/crashes while trying to handle a syntax error, apparently. -- |
From @geeknikThe original test case that I fed to AFL was this: #!/usr/local/bin/perl After about 25 million iterations, that script was turned into the test |
From @geeknikThe afl-gcc is available as part of American Fuzzy Lop which you can obtain |
From @cpansproutOn Sat Jan 03 14:50:18 2015, brian.carpenter@gmail.com wrote:
Yes, it should. I don’t get a crash when I run the script. I do get a panic message, though, in bleadperl and in 5.20.1. 5.18.3 just shows ‘normal’ errors, no panics. I’m going to run a bisect. -- Father Chrysostomos |
From @cpansproutOn Sat Jan 03 17:35:31 2015, sprout wrote:
31f05a3 is the first bad commit Work properly under UTF-8 LC_CTYPE locales -- Father Chrysostomos |
From @cpansproutOn Sat Jan 03 18:00:41 2015, sprout wrote:
Reduced case. This appears to have nothing to do with the syntax error. /TffffffffffffTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT5TT The output I get is: panic: reg_node overrun trying to emit 0, 7fcdf140cca8>=7fcdf140cca4 at /Users/sprout/Downloads/crash line 7. With some variations of the above, I got malloc errors. -- Father Chrysostomos |
From @khwilliamsonOn 01/03/2015 08:39 PM, Father Chrysostomos via RT wrote:
I didn't get these errors, but I did see some valgrind issues, which the |
From @khwilliamson0003-Trial-patch-for-perl-123539-Segmentation-Fault-in-Pe.patchFrom 29adfaedc3d0dec9ff288c7c40642e85018b57cf Mon Sep 17 00:00:00 2001
From: Karl Williamson <khw@cpan.org>
Date: Sat, 3 Jan 2015 22:30:05 -0700
Subject: [PATCH 3/3] Trial patch for [perl #123539] Segmentation Fault in Perl
5.21.8
---
regcomp.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/regcomp.c b/regcomp.c
index 78c614d..82d45e8 100644
--- a/regcomp.c
+++ b/regcomp.c
@@ -12444,7 +12444,9 @@ tryagain:
&& is_PROBLEMATIC_LOCALE_FOLD_cp(ender)))
{
if (UTF) {
- const STRLEN unilen = reguni(pRExC_state, ender, s);
+ const STRLEN unilen = (SIZE_ONLY && ! FOLD)
+ ? UNISKIP(ender)
+ : (uvchr_to_utf8((U8*)s, ender) - (U8*)s);
if (unilen > 0) {
s += unilen;
len += unilen;
@@ -12457,6 +12459,9 @@ tryagain:
* cancel out the increment that follows */
len--;
}
+ else if (FOLD) {
+ *(s++) = (char) ender;
+ }
else {
REGC((char)ender, s++);
}
--
1.9.1
|
From @cpansproutOn Sat Jan 03 21:33:22 2015, public@khwilliamson.com wrote:
Yes, it works for me, both with the reduced case and with the original script from this ticket. I have no idea how it works, though. -- Father Chrysostomos |
From @jkeenanOn Sat Jan 03 21:33:22 2015, public@khwilliamson.com wrote:
The patch works for me as well. With it I get normal syntax errors as shown by the attachment. Thank you very much. -- |
From @jkeenanBareword found where operator expected at /home/jkeenan/learn/perl/p5p/noshebang-123539-crash line 21, near "HHHHHHHHHHHHHHHHHHHH" |
From @hvds"Father Chrysostomos via RT" <perlbug-followup@perl.org> wrote: I don't understand the fix either, but I was able to come up with a % ./perl -we '/bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbAAbbb/il' That's the first hit (len=130, pos1=125, pos2=126) from this search: #!./perl I also don't know what's special about [AFHIJSTWY], but I assume they relate With Karl's suggested patch, the search completes without seeing any problems. Hugo |
From @demerphqOn 4 January 2015 at 14:20, <hv@crypt.org> wrote:
Just to explain, I am pretty sure the key part of the patch is: - const STRLEN unilen = reguni(pRExC_state, ender, s); The regex engine does two compile passes over the pattern (the first Prior to Karl's patch it looks like we would try to write to the Hugo: bear in mind that the logic in study_chunk() fires AFTER the cheers, |
From @hvdsdemerphq <demerphq@gmail.com> wrote: It's the other way round isn't it? reguni() will just return the size Looking further I see this, way further up: Hugo |
From @demerphqOn 5 January 2015 at 17:28, <hv@crypt.org> wrote:
Yes, I missed that.
Indeed. Sorry for the misdirection. Cheers, -- |
From @khwilliamsonFixed in blead by |
|
@khwilliamson - Status changed from 'open' to 'pending release' |
From @khwilliamsonOn Tue Jan 06 14:11:00 2015, khw wrote:
which is suitable for a maintenance release. Here's the text of that commit message: This is a minimal patch suitable for a maintenance release. It extracts This bug is due to the current two pass structure of the Perl regular When not under /i matching, the size of a node that will match a But there is another reason that we have to fold in the sizing pass. (We don't fold non-UTF-8 patterns. This is for two reasons. One is Then there is the complication of matching under locale rules. This bug |
From [Unknown Contact. See original ticket]On Tue Jan 06 14:11:00 2015, khw wrote:
which is suitable for a maintenance release. Here's the text of that commit message: This is a minimal patch suitable for a maintenance release. It extracts This bug is due to the current two pass structure of the Perl regular When not under /i matching, the size of a node that will match a But there is another reason that we have to fold in the sizing pass. (We don't fold non-UTF-8 patterns. This is for two reasons. One is Then there is the complication of matching under locale rules. This bug |
From @demerphqOn 6 January 2015 at 23:16, Karl Williamson via RT
++ Nice explanation. Yves -- |
From @hvds"Karl Williamson via RT" <perlbug-comment@perl.org> wrote: Thanks Karl, that's very clear. So I assume we ended up splitting in pass 2 (or 3) resulting in a size I think there'd be value in having a test for this that's more minimal Hugo [1] % ./perl -we '/bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbAAbbb/il' |
From @khwilliamsonOn 01/07/2015 02:04 AM, hv@crypt.org wrote:
The problem was that it was reading uninitialized memory in pass 1.
The reason I went with the test I did was that it had a bunch of f's in Patches welcome.
|
From @hvdsKarl Williamson <public@khwilliamson.com> wrote: Ah, this is the bit I was missing; I understand now why reproducing it Hugo |
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#123539 (status was 'resolved')
Searchable as RT123539$
The text was updated successfully, but these errors were encountered: