panic: reg_node overrun in unusual regular expression #14891
Comments
From @dcollinsnGreetings Porters, I have compiled bleadperl with the afl-gcc compiler using: ./Configure -Dusedevel -Dprefix='/usr/local/perl-afl' -Dcc=afl-gcc -Duselongdouble -Duse64bitint -Doptimize=-g -Uversiononly -Uman1dir -Uman3dir -Dusethreads -des And then fuzzed the resulting binary using: AFL_NO_VAR_CHECK=1 afl-fuzz -i in -o out bin/perl @@ After reducing testcases using `afl-tmin` and filtering out testcases that are merely iterations of "#!perl -u", I have located the following testcase that triggers a panic in the perl interpreter. The testcase is the 62-byte binary file: (octal bytes) root@nagios:/usr/local/perl-afl/out# od -c allcrash/f2i000000 When executed, the following bad things happen: panic: reg_node overrun trying to emit 0, 8833280>=8833280 at test line 1. The program exits cleanly, apart from the panic, so there is no backtrace for GDB to produce, and Valgrind finds no errors. The next bug I am about to submit is an even more esoteric version of this case which fails somewhat more spectacularly. **PERL -V** Summary of my perl5 (revision 5 version 23 subversion 3) configuration: Characteristics of this binary (from libperl): |
From @dcollinsnGreetings Porters, I have compiled bleadperl with the afl-gcc compiler using: ./Configure -Dusedevel -Dprefix='/usr/local/perl-afl' -Dcc=afl-gcc -Duselongdouble -Duse64bitint -Doptimize=-g -Uversiononly -Uman1dir -Uman3dir -Dusethreads -des And then fuzzed the resulting binary using: AFL_NO_VAR_CHECK=1 afl-fuzz -i in -o out bin/perl @@ After reducing testcases using `afl-tmin` and filtering out testcases that are merely iterations of "#!perl -u", I have located the following testcase that triggers a panic in the perl interpreter. The testcase is the 74-byte binary file: (octal bytes) root@nagios:/usr/local/perl-afl/out# od -c allcrash/f2i000000 Attached as "f2i000000". I'm reasonably certain that this is a duplicate of another bug, because I've seen the below sort of backtrace in a different bug, that also related to a "creative" regular expression. However, I can't find that bug. I'm also not sure if this is an upstream, because Perl is trying to croak here, and does so successfully under very similar circumstances. When executed, the following bad things happen: root@nagios:/usr/local/perl-afl/out# ../bin/perl allcrash/f2i000000 When Perl is instead configured with PERL_MALLOC_WRAP and DEBUGGING, or when the testcase is shortened by removing even one zero, an error such as the following appears, which I've reported as a separate bug, [perl #125990] panic: reg_node overrun trying to emit 0, a18b1fc>=a18b1f8 at test line 1. **GDB** (the above output, followed by...) **VALGRIND** Valgrind seems to cause different behavior in this testcase, allowing Perl to panic rather than throw the glibc error above. Not sure how to get around that. ==9005== Memcheck, a memory error detector **BISECT** First commit that crashes in this particular way is: Empty \N{} in regex pattern should force /d to /u **PERL -V** Summary of my perl5 (revision 5 version 23 subversion 3) configuration: Characteristics of this binary (from libperl): |
From @dcollinsn |
From @tonycozOn Fri Sep 04 17:27:40 2015, dcollinsn@gmail.com wrote:
Could you attach this file please? Thanks, |
|
The RT System itself - Status changed from 'new' to 'open' |
From @tonycozOn Sun Sep 06 21:20:19 2015, tonyc wrote:
I ended up generating it, attached as 125990.pl. The problem is len at line 12988 is different between pass 1 and pass 2, with values of 54 and 57. This leads to a simplified reproducer: tony@mars:.../git/perl$ od -c ../125990b.pl attached as 125990b.pl, which should be simpler to debug to find where the mismatch occurs (which I'll do tomorrow if someone else doesn't beat me to it.) Tony |
From @tonycoz |
From @tonycozOn Mon Sep 07 23:57:17 2015, tonyc wrote:
RT seems to have attached the same content for both files. Trying 125990.pl again. Tony |
From @khwilliamsonThis is likely from my code, so I'm taking the ticket to look at it. On 09/08/2015 12:58 AM, Tony Cook via RT wrote:
|
From @tonycozOn Fri Sep 04 17:28:18 2015, dcollinsn@gmail.com wrote:
I strongly suspect this is the same bug as 125990. The base case of 125990 has enough ß (ss) characters for the generated string to take up the space for one extra regnode over the calculated length, the case in this ticket overflows even further. Your case doesn't produce an error (even with valgrind) on my 64-bit system, but a modified (and shorter version) can be made to: tony@mars:.../git/perl$ od -c ../125991b.pl though it's only errors for me with valgrind.
I expect this is caused by the buffer overflow from the above corrupting the malloc() arena.
While in this case it's \N{} forcing the regexp to be unicode, other mechanisms can cause it too: tony@mars:.../git/perl$ od -c ../125991c.pl Tony |
From @tonycoz |
From @tonycoz |
|
The RT System itself - Status changed from 'new' to 'open' |
From @tonycozOn Tue Sep 08 08:04:55 2015, public@khwilliamson.com wrote:
Ok, 125991 looks like the same bug (but a larger overflow that corrupts the memory arena). Tony |
From @khwilliamsonThanks for finding this. I have figured out the cause, and am now contemplating the best solution. Tony Cook was correct that #125990 and #125991 are from the same cause, and so I have merged the two tickets. This bug arises when a pattern is compiled under /id rules, has a ß in it, and has something else in it, such as a \p or a \N{}, that causes it to switch to /iu rules. The latter will try to fold the ß to 'ss', the former does not. Thus the latter takes up 2 bytes and the former takes up 1. The sizing pass is done under /id rules, and the allocation pass is done under /iu, so the space allocated is less than the space actually used, and you get the problem. Anything under compiled under 'use 5.012' or higher or 'use utf8' is by default compiled with /u rules, so this bug won't likely appear in such code. One would have to explicitly say /d to override the default; this is unlikely. Karl Williamson |
From @khwilliamsonFixed by commit 512c0f5 whose message is below: This is a result of a design flaw that I introduced in earlier releases |
|
@khwilliamson - Status changed from 'open' to 'pending release' |
From @khwilliamsonThank you for submitting this report. You have helped make Perl better. Perl 5.24.0 may be downloaded via https://metacpan.org/release/RJBS/perl-5.24.0 |
|
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#125990 (status was 'resolved')
Searchable as RT125990$
The text was updated successfully, but these errors were encountered: