Re: AddressSanitizer: heap-buffer-overflow in rl_delete

[Chet Ramey]

On 6/16/17 10:27 AM, Eduardo A. Bustamante López wrote:
> On Thu, Jun 15, 2017 at 09:36:58AM -0500, Eduardo Bustamante wrote:
>> Found by fuzzing `read -e' with AFL. The stacktrace reported by Address
>> Sanitizer is followed by the base64 encoded crashing input.
>>
>>
>> ==1736==ERROR: AddressSanitizer: heap-buffer-overflow on address 
>> 0x611000009880 at pc 0x7f464da3a063 bp 0x7ffe86032fe0 sp 0x7ffe86032790
>> READ of size 115 at 0x611000009880 thread T0
>>     #0 0x7f464da3a062  (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x3c062)
>>     #1 0x5634e38634c3 in _rl_find_next_mbchar_internal 
>> (/home/dualbus/src/gnu/bash-build/bash+0x25d4c3)
>>     #2 0x5634e3864375 in _rl_find_next_mbchar 
>> (/home/dualbus/src/gnu/bash-build/bash+0x25e375)
>>     #3 0x5634e3850c0e in rl_delete 
>> (/home/dualbus/src/gnu/bash-build/bash+0x24ac0e)
> 
> OK. Here's an easy way to reproduce this.
> 
> - Start on an empty rl_line_buffer
> - Call `set-mark' with a numeric argument (a large number, e.g. 500, is 
> better).
> - Call `exchange-point-and-mark' so that now rl_point = 500
> - Call `delete-char'
> - Bash crashes

I can't reproduce this using the current development version. Its failure
depends on rl_end already being wrong.  I've already fixed that particular
problem; it was a problem with the isearch code that requires the obscure
circumstances fuzzing brings to reproduce.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/