develooper Front page | perl.perl5.porters | Postings from April 2019

Re: [perl #134064] Assertion failure in S_scan_const (toke.c:4063)

Thread Previous
From:
Karl Williamson
Date:
April 29, 2019 22:03
Subject:
Re: [perl #134064] Assertion failure in S_scan_const (toke.c:4063)
Message ID:
7978ed6d-a4ec-d2a6-0488-59bb15aa930b@khwilliamson.com
On 4/26/19 9:05 AM, Sergey Aleynikov (via RT) wrote:
> # New Ticket Created by  Sergey Aleynikov
> # Please include the string:  [perl #134064]
> # in the subject line of all future correspondence about this issue.
> # <URL: https://rt.perl.org/Ticket/Display.html?id=134064 >
> 
> 
> This is a bug report for perl from sergey.aleynikov@gmail.com,
> generated with the help of perlbug 1.41 running under perl 5.29.9.
> 
> 
> -----------------------------------------------------------------
> [Please describe your issue here]
> 
> While fuzzing perl v5.29.10-23-g7c0d7520a3 built with afl and run
> under libdislocator, I found the following program
> 
> use utf8;
> $foo="m'\300'";eval$foo
> 
> To cause an assertion failure
> 
> perl: toke.c:4063: char *S_scan_const(char *): Assertion
> `isUTF8_CHAR((U8 *) s, (U8 *) send)' failed.
> 
> GDB stack trace is following
> 
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x00007ffff7c25535 in __GI_abort () at abort.c:79
> #2  0x00007ffff7c2540f in __assert_fail_base (fmt=0x7ffff7d87ee0
> "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
>      assertion=0x55555593ee78 "isUTF8_CHAR((U8 *) s, (U8 *) send)",
> file=0x5555559383e5 "toke.c", line=4063, function=<optimized out>) at
> assert.c:92
> #3  0x00007ffff7c330f2 in __GI___assert_fail (assertion=0x55555593ee78
> "isUTF8_CHAR((U8 *) s, (U8 *) send)", file=0x5555559383e5 "toke.c",
> line=4063,
>      function=0x55555595da28 <__PRETTY_FUNCTION__.18843>
> "S_scan_const") at assert.c:101
> #4  0x00005555556308aa in S_scan_const (start=0x555555b6a170 "\300")
> at toke.c:4063
> #5  0x0000555555638f3b in Perl_yylex () at toke.c:5096
> #6  0x000055555566bde0 in Perl_yyparse (gramtype=258) at perly.c:340
> #7  0x0000555555839ec6 in S_doeval_compile (gimme=1 '\001',
> outside=0x555555b53908, seq=4294967256, hh=0x0) at pp_ctl.c:3502
> #8  0x0000555555841c61 in Perl_pp_entereval () at pp_ctl.c:4478
> #9  0x000055555570c635 in Perl_runops_debug () at dump.c:2537
> #10 0x00005555555ed63d in S_run_body (oldscope=1) at perl.c:2716
> #11 0x00005555555ecbbb in perl_run (my_perl=0x555555b51260) at perl.c:2639
> #12 0x00005555555a1181 in main (argc=3, argv=0x7fffffffe1c8,
> env=0x7fffffffe1e8) at perlmain.c:134
> 
> This is a regression in blead, bisect points to
> 
> commit 7d6e74d636b95acb75fa67ff364e97ab1c8ef795
> Author: Karl Williamson <khw@cpan.org>
> Date:   Sat Apr 6 14:05:29 2019 -0600
> 
>      toke.c: Streamline a case
> 
>      When we are parsing a constant, and the source and destination differ in
>      UTF-8ness, I realized, in single stepping through the code, that it's
>      simpler and more efficient to split these into two cases, rather than
>      try to do one case with some conditionals in the middle.
> 

The attached one word patch fixes this.  This bug report illustrates my 
point in a recent post about these fuzzer failures from Sergey being 
something that should concern us.  The actual problem is that string 
eval is not being checked for UTF-8 well-formedness when 'use utf8' is 
in effect.

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