https://sourceware.org/bugzilla/show_bug.cgi?id=33051
Bug ID: 33051
Summary: ASAN: heap-buffer-overflow
../../src/libsframe/sframe.c:1054 in
sframe_get_funcdesc_with_addr_internal
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: libsframe
Assignee: indu.bhagat at oracle dot com
Reporter: jamborm at gcc dot gnu.org
CC: jremus at linux dot ibm.com
Target Milestone: ---
Host: x86_64-linux-gnu
Target: aarch64-elf
With the current binutils checkout (commit a8f4696286a), when
configured to use the address sanitizer and to build cross binutils
from x86_64-linux to Aarch64 with:
../src/configure --build=x86_64-linux --disable-gdb --disable-gdbserver
--disable-werror --enable-obsolete --target=aarch64-elf CFLAGS="-g -O2
-fsanitize=address,undefined -Wno-error" CXXLAGS="-g -O2
-fsanitize=address,undefined -Wno-error" LDFLAGS="-ldl"
and exporting environment variable: ASAN_OPTIONS=detect_leaks=0
and then building and running the testsuite with make -k check, I'm
seeing the following failures in ./libsframe/libsframe.log
=================================================================
==3145259==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x7be03a1e011c at pc 0x0000004094d1 bp 0x7ffe3614d490 sp 0x7ffe3614d488
READ of size 4 at 0x7be03a1e011c thread T0
PASS: findfunc-1: Encoder write
PASS: findfunc-1: Decoder setup
PASS: findfunc-1: test-1: Find FRE for PC not in range
PASS: findfunc-1: test-2: Find FRE for PC not in range
PASS: findfunc-1: test-3: Find FRE for PC not in range
#0 0x0000004094d0 in sframe_get_funcdesc_with_addr_internal
../../src/libsframe/sframe.c:1054
#1 0x0000004094d0 in sframe_find_fre ../../src/libsframe/sframe.c:1114
#2 0x000000403cc0 in test_text_findfre
../../src/libsframe/testsuite/libsframe.find/findfunc-1.c:212
#3 0x0000004025f8 in main
../../src/libsframe/testsuite/libsframe.find/findfunc-1.c:246
#4 0x7f803b42b12d in __libc_start_call_main (/lib64/libc.so.6+0x2b12d)
(BuildId: 4e306825df357f9b661479a3f9d24a8dbf960c1f)
#5 0x7f803b42b1f8 in __libc_start_main_impl (/lib64/libc.so.6+0x2b1f8)
(BuildId: 4e306825df357f9b661479a3f9d24a8dbf960c1f)
#6 0x0000004026b4 in _start ../sysdeps/x86_64/start.S:115
0x7be03a1e011c is located 0 bytes after 60-byte region
[0x7be03a1e00e0,0x7be03a1e011c)
allocated by thread T0 here:
#0 0x7f803c121c0b in malloc (/lib64/libasan.so.8+0x121c0b) (BuildId:
9f51e9501f1a177885c12bfa56f55641c3be603e)
#1 0x000000407a7a in sframe_decode ../../src/libsframe/sframe.c:925
SUMMARY: AddressSanitizer: heap-buffer-overflow
../../src/libsframe/sframe.c:1054 in sframe_get_funcdesc_with_addr_internal
Shadow bytes around the buggy address:
0x7be03a1dfe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7be03a1dff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7be03a1dff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7be03a1e0000: fa fa fa fa 00 00 00 00 00 00 05 fa fa fa fa fa
0x7be03a1e0080: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00
=>0x7be03a1e0100: 00 00 00[04]fa fa fa fa fa fa fa fa fa fa fa fa
0x7be03a1e0180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x7be03a1e0200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x7be03a1e0280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x7be03a1e0300: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x7be03a1e0380: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 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
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==3145259==ABORTING
It is kind of funny that no test seems to be FAILing though.
This behavior has been introduced by commit
9d2a24349e23afe3ee5e6ac093ffca3901d39bc5 (Jens Remus: libsframe:
correct binary search for SFrame FDE).
--
You are receiving this mail because:
You are on the CC list for the bug.
