Front page | perl.perl5.porters |
Postings from January 2017
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.
--
"You may not work around any technical limitations in the software"
-- Windows Vista license
Thread Previous