Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upSegmentation 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$