GNU bug report logs -
#16171
ptx: heap buffer overrun, when run with two file arguments
Previous Next
Reported by: Jim Meyering <jim <at> meyering.net>
Date: Tue, 17 Dec 2013 02:24:02 UTC
Severity: normal
Done: Pádraig Brady <P <at> draigBrady.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Mon, 28 Apr 2014 14:52:23 +0100
with message-id <535E5D17.3050700 <at> draigBrady.com>
and subject line Re: bug#16171: ptx: heap buffer overrun, when run with two file arguments
has caused the debbugs.gnu.org bug report #16171,
regarding ptx: heap buffer overrun, when run with two file arguments
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
16171: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16171
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
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
[Message part 3 (message/rfc822, inline)]
[Message part 4 (text/plain, inline)]
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 (text/x-patch, attachment)]
This bug report was last modified 11 years and 82 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.