--- Begin Message ---
|
Subject: |
ptx: heap buffer overrun, when run with two file arguments |
|
Date: |
Mon, 16 Dec 2013 18:22:27 -0800 |
Hi,
I built like this using just-built 4.9.0 20131216
(but it probably would work as well with 4.8.x):
make check AM_CFLAGS='-ggdb3 -static-libasan -fsanitize=address'
AM_LDFLAGS='-fsanitize=address -static-libasan -lpthread -ldl'
and then I ran this,
echo a > a && echo b > b &&
./ptx -g1 -w1 a b 2>&1 | asan_symbolize.py -d
and include its output below.
That output shows a heap-read overrun bug that arises
because ptx was designed to process only one input file, yet
was later extended to process more than, but without some
important adjustments.
The underlying problem is that swallow_file_in_memory (called from main)
is setting the contents of the global text_buffer for the first file,
then updating it (clobbering old value) for the second file.
Yet, some pointers to the initial buffer have been squirreled away
and later, one of them (keyafter) is presumed to point into
the new "text_buffer", which it does not. The subsequent
SKIP_WHITE_BACKWARDS use backs up "cursor" until it is goes
out of bounds.
=================================================================
==3156==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60200000e90f at pc 0x409612 bp 0x7fff67a426c0 sp 0x7fff67a426b8
READ of size 1 at 0x60200000e90f thread T0
#0 0x409611 in generate_all_output /cu/src/ptx.c:1425
#1 0x7f3080a89994 in __libc_start_main
/home/aurel32/eglibc/eglibc-2.17/csu/libc-start.c:276
#2 0x409bb4 in _start ??:?
0x60200000e90f is located 1 bytes to the left of 3-byte region
[0x60200000e910,0x60200000e913)
allocated by thread T0 here:
#0 0x4458e7 in __interceptor_malloc _asan_rtl_
#1 0x462c8b in fread_file /cu/lib/read-file.c:73
SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 ??
Shadow bytes around the buggy address:
0x0c047fff9cd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff9ce0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff9cf0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff9d00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff9d10: fa fa fa fa fa fa fd fd fa fa 03 fa fa fa fd fd
=>0x0c047fff9d20: fa[fa]03 fa fa fa 00 00 fa fa 04 fa fa fa 04 fa
0x0c047fff9d30: fa fa fd fa fa fa fd fa fa fa 00 fa fa fa fd fa
0x0c047fff9d40: fa fa 00 fa fa fa 00 fa fa fa fd fa fa fa fd fa
0x0c047fff9d50: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
0x0c047fff9d60: fa fa fd fa fa fa fd fa fa fa fd fa fa fa 00 fa
0x0c047fff9d70: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 04 fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Contiguous container OOB:fc
ASan internal: fe
==3156==ABORTING
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#16171: ptx: heap buffer overrun, when run with two file arguments |
|
Date: |
Mon, 28 Apr 2014 14:52:23 +0100 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 |
On 12/17/2013 10:29 AM, Pádraig Brady wrote:
> On 12/17/2013 02:22 AM, Jim Meyering wrote:
>> Hi,
>>
>> I built like this using just-built 4.9.0 20131216
>> (but it probably would work as well with 4.8.x):
>>
>> make check AM_CFLAGS='-ggdb3 -static-libasan -fsanitize=address'
>> AM_LDFLAGS='-fsanitize=address -static-libasan -lpthread -ldl'
>>
>> and then I ran this,
>>
>> echo a > a && echo b > b &&
>> ./ptx -g1 -w1 a b 2>&1 | asan_symbolize.py -d
>>
>> and include its output below.
>> That output shows a heap-read overrun bug that arises
>> because ptx was designed to process only one input file, yet
>> was later extended to process more than, but without some
>> important adjustments.
>>
>> The underlying problem is that swallow_file_in_memory (called from main)
>> is setting the contents of the global text_buffer for the first file,
>> then updating it (clobbering old value) for the second file.
>> Yet, some pointers to the initial buffer have been squirreled away
>> and later, one of them (keyafter) is presumed to point into
>> the new "text_buffer", which it does not. The subsequent
>> SKIP_WHITE_BACKWARDS use backs up "cursor" until it is goes
>> out of bounds.
>
> Nice. This is a good illustration how test coverage
> can be leveraged by (future) run time checks.
>
> I see it here too (as the only failure in make check with -fsanitize=address
The attached should address this.
I'll push later.
thanks,
Pádraig.
ptx-whitespace-heap-overflow.patch
Description: Text Data
--- End Message ---