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

Re: [perl #134067] heap-buffer-overflow in S_scan_const(toke.c:4103)

Thread Previous
From:
Karl Williamson
Date:
April 29, 2019 22:31
Subject:
Re: [perl #134067] heap-buffer-overflow in S_scan_const(toke.c:4103)
Message ID:
b166d1de-9ed3-18eb-016e-9203a2a0d360@khwilliamson.com
On 4/27/19 10:28 AM, Sergey Aleynikov (via RT) wrote:
> # New Ticket Created by  Sergey Aleynikov
> # Please include the string:  [perl #134067]
> # in the subject line of all future correspondence about this issue.
> # <URL: https://rt.perl.org/Ticket/Display.html?id=134067 >
> 
> 
> 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 (also attached to
> this message)
> 
> 00000000  79 20 6f 5c 78 7b 31 30  30 7d c4 8c ff ff 80 80  |y o\x{100}......|
> 00000010  2d ff 6f 6f                                       |-.oo|
> 
> 
> This is a regression in blead, bisect points to the following commit,
> and I feel this is a different issue from
> https://rt.perl.org/Ticket/Display.html?id=134064
> 
> 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 patches fix this.  I think this bug has been around before 
the blamed commit, but it exacerbated the problem.  When parsing tr///, 
you can have character ranges like a-z, \x80-\xbf, etc.  The fact that 
it was a range is remembered while the upper number is parsed, then 
afterwards, the upper number is shifted right in the buffer and the 
hyphen is inserted.  This is because the hyphen is usually not needed. 
If the destination buffer of the parse grows after parsing the hyphen 
(in other words, while parsing the upper number), it fails to allocate 
space for it, and can overflow.

The final patch stems from my realization that we could check before 
outputting the terminating NUL if there is space, and grow at that 
point.  This should be done as a safeguard against miscalculations 
earlier.  Doing something like this would have prevented the failure in 
this ticket.

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