develooper Front page | perl.perl5.porters | Postings from August 2017

[perl #130651] regcomp.c:6881: REGEXP *Perl_re_op_compile(SV**const, int, OP *, const regexp_engine *, REGEXP *, _Bool *, U32, U32):Assertion `expr' failed

Thread Previous
From:
Tony Cook via RT
Date:
August 23, 2017 05:46
Subject:
[perl #130651] regcomp.c:6881: REGEXP *Perl_re_op_compile(SV**const, int, OP *, const regexp_engine *, REGEXP *, _Bool *, U32, U32):Assertion `expr' failed
Message ID:
rt-4.0.24-17780-1503467194-1941.130651-15-0@perl.org
On Fri, 27 Jan 2017 07:05:43 -0800, davem wrote:
> On Thu, Jan 26, 2017 at 07:13:37AM -0800, Sergey Aleynikov wrote:
> > While fuzzing perl v5.25.9-35-g32207c637b built with afl and run
> > under libdislocator, I found the following program
> > 
> > qr!@{return%0}0[(?{!
> 
> A bit of an edge case this. runtime qr//s which include code blocks
> are wrapped in a hidden sub to make all the closurey stuff work correctly.
> So for example
> 
>     $r = qr/a$b(?{...})/
> 
> is roughly equivalent to
> 
>     @args = sub {
>                 ('a', $b, sub{...});
>             }->();
>     $args = join '', @args;
>     $r = qr/$args/
> 
> (except that the inner sub isn't actually a separate anon sub - its just a
> code block compiled as part of the outer anon sub, and the code block gets
> passed to the regex compiler as-is rather than being stringified and
> concatenated.)
> 
> The 'return' inside the @{...} expression is causing a return from the
> hidden sub, returning nothing, which then causes an assert fail inside
> Perl_re_op_compile, since its expecting at least 1 arg.
> 
> The most immediate fix would be to make Perl_re_op_compile() robust in the
> presence of no (or unexpected) args, but it is semantically incorrect.
> The return should cause a return out of two levels of sub - the hidden
> one, and the expected one which the qr// is enclosed in. There's already
> a mechanism for returning from two nested subs: CXp_SUB_RE_FAKE; but
> I don't yet see an easy way to get it set in this case, without
> polluting pp_entersub with more flags and special cases.
> 
> I need to think some more.

If I understand correctly, this is bug in interpolation - and isn't a security issue.

Is that correct?

Tony

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=130651

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About