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 c...@case.edu http://cnswww.cns.cwru.edu/~chet/
