Unknown regexp modifier/unmatched [ becomes Assertion `(IV)elen >= 0' failed. #14965
Comments
From @dcollinsnGreetings Porters, I have compiled bleadperl with the afl-gcc compiler using: ./Configure -Dusedevel -Dprefix='/usr/local/perl-afl' -Dcc='ccache afl-gcc' -Duselongdouble -Duse64bitall -Doptimize=-g -Uversiononly -Uman1dir -Uman3dir -DDEBUGGING -DPERL_POISON -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 performing additional minimization by hand, I have located the following testcase that triggers an assert fail in the perl interpreter, but which (correctly) errors out in non-debugging perl. The simplest testcase is the file: dcollins@nightshade64:/usr/local/perl-afl/out$ od -c allcrash/perlu/f3i000270 In a not-debugging perl, the output is: In a debugging perl, the output is: **GDB** Program received signal SIGABRT, Aborted. **VALGRIND** **PERL -V** Characteristics of this binary (from libperl): |
From @dcollinsn |
From @iabynOn Sun, Oct 04, 2015 at 12:41:26PM -0700, Dan Collins wrote:
It can be reduced to this: /[\x{df}[.00./i; At its heart, it's because S_regclass(), when confronted with weirdo chars The basic fix seems simple; just localise RExC_precomp at the same time as However, when I tried to add a test in t/re/reg_mesg.t, I ran into two First, the error message lists the faked-up pattern being recursively Second, reg_mesg.t tests each entry twice, without and with "use re $ p -e'/[\x{DF}[.00./i' $ p -e'use re "strict"; /[\x{DF}[.00./i' I don't know whether that's intentional or not. I then got into what what exactly triggered the error, and whether it I came to the conclusion that I'm a bit out of my depth here, and am -- |
From @iabynprecomp.diffdiff --git a/regcomp.c b/regcomp.c
index 059745d..c810284 100644
--- a/regcomp.c
+++ b/regcomp.c
@@ -15443,6 +15443,7 @@ S_regclass(pTHX_ RExC_state_t *pRExC_state, I32 *flagp, U32 depth,
STRLEN len;
char *save_end = RExC_end;
char *save_parse = RExC_parse;
+ char *save_precomp = RExC_precomp;
bool first_time = TRUE; /* First multi-char occurrence doesn't get
a "|" */
I32 reg_flags;
@@ -15496,6 +15497,7 @@ S_regclass(pTHX_ RExC_state_t *pRExC_state, I32 *flagp, U32 depth,
#endif
RExC_parse = SvPV(substitute_parse, len);
+ RExC_precomp = RExC_parse;
RExC_end = RExC_parse + len;
RExC_in_multi_char_class = 1;
RExC_override_recoding = 1;
@@ -15505,6 +15507,7 @@ S_regclass(pTHX_ RExC_state_t *pRExC_state, I32 *flagp, U32 depth,
*flagp |= reg_flags&(HASWIDTH|SIMPLE|SPSTART|POSTPONED|RESTART_PASS1|NEED_UTF8);
+ RExC_precomp = save_precomp;
RExC_parse = save_parse;
RExC_end = save_end;
RExC_in_multi_char_class = 0;
diff --git a/t/re/reg_mesg.t b/t/re/reg_mesg.t
index 62e3e4a..478ddeb 100644
--- a/t/re/reg_mesg.t
+++ b/t/re/reg_mesg.t
@@ -263,6 +263,7 @@ my @death =
'/(?[\ &!])/' => 'Incomplete expression within \'(?[ ])\' {#} m/(?[\ &!{#}])/', # [perl #126180]
'/(?[()-!])/' => 'Incomplete expression within \'(?[ ])\' {#} m/(?[()-!{#}])/', # [perl #126204]
'/(?[!()])/' => 'Incomplete expression within \'(?[ ])\' {#} m/(?[!(){#}])/', # [perl #126404]
+ '/[\x{DF}[.00./i' => 'Unmatched [ {#} m/?:\x{DF}|[{#}\x{DF}[.00.])/', # [perl #126261]
);
# These are messages that are warnings when not strict; death under 'use re
|
|
The RT System itself - Status changed from 'new' to 'open' |
From @khwilliamsonOn 12/03/2015 03:10 AM, Dave Mitchell wrote:
I added the code that fails, and didn't think about this case. This
It's sort of intentional, but can be improved on.
I have had a work long-in-progress to fix up the POSIX class things. |
From @khwilliamsonThis is now fixed by commit 285b5ca Thanks for the report |
|
@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#126261 (status was 'resolved')
Searchable as RT126261$
The text was updated successfully, but these errors were encountered: