[perl #130632] Memory leak in Perl_yylex (toke.c:7027)

On Tue, 24 Jan 2017 00:19:10 -0800, randir wrote:
> While fuzzing perl v5.25.8-216-gfbceb79751 built with afl and run
> under libdislocator, I found the following program
> 
> s//'x' ^ -"s:\347"/eeg
> 
> to cause a memory leak report under ASAN:
> 
> =================================================================
> ==27209==ERROR: LeakSanitizer: detected memory leaks
> 
> Direct leak of 4 byte(s) in 1 object(s) allocated from:
>     #0 0x4ea6c8 in malloc (/home/afl/afl-asan/perl+0x4ea6c8)
>     #1 0x8504be in Perl_safesysmalloc /home/afl/afl-asan/util.c:153:21
>     #2 0x8564ab in Perl_savepvn /home/afl/afl-asan/util.c:1177:5
>     #3 0x675843 in Perl_yylex /home/afl/afl-asan/toke.c:7027:23
>     #4 0x6f6072 in Perl_yyparse /home/afl/afl-asan/perly.c:340:34
>     #5 0xb0c78f in S_doeval_compile /home/afl/afl-
> asan/pp_ctl.c:3432:77
>     #6 0xb09a17 in Perl_pp_entereval /home/afl/afl-
> asan/pp_ctl.c:4292:9
>     #7 0x84b114 in Perl_runops_debug /home/afl/afl-asan/dump.c:2406:23
>     #8 0x5f1b05 in S_run_body /home/afl/afl-asan/perl.c:2528:2
>     #9 0x5f1b05 in perl_run /home/afl/afl-asan/perl.c:2451
>     #10 0x5224d2 in main /home/afl/afl-asan/perlmain.c:123:9
>     #11 0x7efca17d02b0 in __libc_start_main
> (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
> 
> SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
> 
> Leaked scalar comes from the following line
> 
> pl_yylval.pval = savepvn(PL_tokenbuf, len+1);
> 
> In this case PL_tokenbuf is "Us" and len == 2. Amount of memory leaked
> scales with the size of this buffer. For example, the following
> eternal loop leaks 20 bytes per iteration, so run it with caution:
> 
> s//'x' ^ -"s666666666666666k:\347"/eeg while (1)

This looks like it's fixed, I expect by:

commit 017192018b7f9fc4b889bb344bd75df8f6b78929
Author: David Mitchell <davem@iabyn.com>
Date:   Fri Apr 5 12:49:50 2019 +0100

    parser: change LABEL type from pval to opval
    
    The items pushed onto the parser stack can be one of several types:
    ival, opval, pval etc. The only remaining use of pval is when a "label:"
    is encountered.
    
    When an error occurs during parsing, ops on the parse stack get
    automatically reaped these days as part of the OP slab mechanism;
    but bare strings (pvals) still leak.
    
    Convert this one remaining pval into an opval, making the toker return
    an OP_CONST with an SV holding the label.
    
    Since newSTATEOP() still expects a raw string for the label, the parser
    just grabs the value returned by the toker and makes a copy of the
    string from it, then immediately frees the OP_CONST and its associated
    SV.
    
    The leak was showing up in ext/XS-APItest/t/stmtasexpr.t, which expects
    to parse a statement where labels are banned.

Tony

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

• [perl #130632] Memory leak in Perl_yylex (toke.c:7027) by Tony Cook via RT