[perl #129061] Valgrind: Buffer overrun in S_regmatch withpathological regular expression

On Tue Aug 23 19:48:57 2016, dcollinsn@gmail.com wrote:
> Detected using AFL and libdislocator, but reproducible with valgrind
> and an uninstrumented perl.
> 
> The following regex causes a length-1 buffer to be allocated, but the
> second element of that buffer to be read, at two different points in
> S_regmatch. The buffer in question is reginfo->info_aux->poscache:
> 
> perl -e '/0*()*(||0(?0))^*0^+|(?0)(?0)/'
> 
> The only visible output of this script is the message:
> 
> But under debugging tools:
> 
> %% VALGRIND %%
> 
> ==40309== Invalid read of size 1
> ==40309==    at 0xCB7E52: S_regmatch (regexec.c:7471)
> ==40309==    by 0xCB7E52: S_regtry (regexec.c:3619)
> ==40309==    by 0xD1A01D: Perl_regexec_flags (regexec.c:3486)
> ==40309==    by 0x8FD147: Perl_pp_match (pp_hot.c:1836)
> ==40309==    by 0x7E0833: Perl_runops_debug (dump.c:2234)
> ==40309==    by 0x53A0D8: S_run_body (perl.c:2525)
> ==40309==    by 0x53A0D8: perl_run (perl.c:2448)
> ==40309==    by 0x429A47: main (perlmain.c:123)
[...]

The docs added by davem in 1cb95af7 say:

    * The top 4 bits of scan->flags byte say how many different
    * relevant CURLLYX/WHILEM op pairs there are, while the
    * bottom 4-bits is the identifying index number of this
    * WHILEM.

.. and the code certainly appears to think that, using the top 4 bits to decide the size of poscache to malloc, and the bottom 4 bits to decide the index to look at. The invalid read occurs here because scan->flags == 0x3b, so something is violating that expectation; I don't yet know whether the expectation was wrong in the first place or something is abusing it.

Hugo

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

• [perl #129061] Valgrind: Buffer overrun in S_regmatch withpathological regular expression by Hugo van der Sanden via RT