[Bug sanitizer/91115] New: stack-buffer-overflow on memset local variable when creating thread on ARM Linux
fhsueh at roku dot com
gcc-bugzilla@gcc.gnu.org
Mon Jul 8 19:14:00 GMT 2019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91115
Bug ID: 91115
Summary: stack-buffer-overflow on memset local variable when
creating thread on ARM Linux
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: fhsueh at roku dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
I'm getting a ASAN stack-buffer-overflow when thread is starting on ARM Linux.
gcc-8.3 and glibc-2.22. Here's the output, cleaned up a bit:
>>>>>
==1541==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x9bffebf8 at
pc 0xa3585e98 bp 0x9bffebc4 sp 0x9bffe790
WRITE of size 36 at 0x9bffebf8 thread T10
#0 0xa3585e97 in __interceptor_memset
gcc-8.3.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:709
#1 0x9f6d378b in __pthread_attr_init_2_1
glibc-2.22/nptl/pthread_attr_init.c:41
#2 0xa3619053 in __sanitizer::GetThreadStackTopAndBottom(bool, unsigned
long*, unsigned long*)
gcc-8.3.0/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:105
#3 0xa361940b in __sanitizer::GetThreadStackAndTls(bool, unsigned long*,
unsigned long*, unsigned long*, unsigned long*)
gcc-8.3.0/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:415
#4 0xa360f147 in
__asan::AsanThread::SetThreadStackAndTls(__asan::AsanThread::InitOptions
const*) gcc-8.3.0/libsanitizer/asan/asan_thread.cc:287
#5 0xa360f237 in __asan::AsanThread::Init(__asan::AsanThread::InitOptions
const*) gcc-8.3.0/libsanitizer/asan/asan_thread.cc:224
#6 0xa360f367 in __asan::AsanThread::ThreadStart(unsigned long,
__sanitizer::atomic_uintptr_t*) gcc-8.3.0/libsanitizer/asan/asan_thread.cc:241
#7 0x9f6d1d63 in start_thread glibc-2.22/nptl/pthread_create.c:336
Address 0x9bffebf8 is located in stack of thread T9 at offset 664 in frame
#0 0x25b6e3f in _M_run arm-roku-linux-gnueabi/include/c++/8.3.0/thread:196
This frame has 13 object(s):
[32, 36) 'bt'
[96, 100) 'bt'
[160, 168) '<unknown>'
[224, 232) '<unknown>'
[288, 296) '<unknown>'
[352, 360) '<unknown>'
[416, 424) '<unknown>'
[480, 488) '<unknown>'
[544, 552) 'lock'
[608, 620) 'cd'
[672, 684) 'cd' <== Memory access at offset 664 partially underflows this
variable
[736, 748) '<unknown>'
[800, 812) '<unknown>'
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
Thread T9 created by T0 here:
#0 0xa35cdc1f in __interceptor_pthread_create
gcc-8.3.0/libsanitizer/asan/asan_interceptors.cc:202
#1 0x9f83d543 in
std::thread::_M_start_thread(std::unique_ptr<std::thread::_State,
std::default_delete<std::thread::_State> >, void (*)())
(/usr/lib/libstdc++.so.6+0x9c543)
SUMMARY: AddressSanitizer: stack-buffer-overflow
gcc-8.3.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:709
in __interceptor_memset
Shadow bytes around the buggy address:
0x437ffd20: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
0x437ffd30: 04 f2 f2 f2 f2 f2 f2 f2 04 f2 f2 f2 f2 f2 f2 f2
0x437ffd40: 00 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f2 f2 f2 f2
0x437ffd50: 00 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f2 f2 f2 f2
0x437ffd60: 00 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f2 f2 f2 f2
=>0x437ffd70: 00 f2 f2 f2 f2 f2 f2 f2 00 04 f2 f2 f2 f2 f2[f2]
0x437ffd80: 00 04 f2 f2 f2 f2 f2 f2 00 04 f2 f2 f2 f2 f2 f2
0x437ffd90: 00 04 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00
0x437ffda0: 00 00 00[ 363.983356] grsec: bruteforce prevention initiated for
the next 30 minutes or until service restarted, stalling each fork 30 seconds.
Please investigate the crash report for /bin/Application[Application:1541]
uid/euid:0/0 gid/egid:0/0, parent /bin/Application[Application:1480]
uid/euid:501/501 gid/egid:501/501
00 00 00 00 00 00 00 00 00 00 00 00 00
0x437ffdb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x437ffdc0: 00 00 00 00 364.068455] ltcore_dump: starting dump
m 00 00 00 00 00 00 grsec: From 10.14.24.38: denied resource overstep by
requesting 52 for RLIMIT_CORE against limit 0 for
/bin/Application[Application:1542] uid/euid:501/501 gid/egid:501/501, parent
/bin/busybox[sh:1394] uid/euid:0/0 gid/egid:0/0
[1m 00 grsec: From 10.14.24.38: denied resource overstep by requesting 84 for
RLIMIT_CORE against limit 0 for /bin/Application[Application:1542]
uid/euid:501/501 gid/egid:501/501, parent /bin/busybox[sh:1394] uid/euid:0/0
gid/egid:0/0
[0m00 00[ 364.128767] grsec: From 10.14.24.38: denied resource overstep by
requesting 116 for RLIMIT_CORE against limit 0 for
/bin/Application[Application:1542] uid/euid:501/501 gid/egid:501/501, parent
/bin/busybox[sh:1394] uid/euid:0/0 gid/egid:0/0
00 00 364.152847] grsec: From 10.14.24.38: denied resource overstep by
requesting 148 for RLIMIT_CORE against limit 0 for
/bin/Application[Application:1542] uid/euid:501/501 gid/egid:501/501, parent
/bin/busybox[sh:1394] uid/euid:0/0 gid/egid:0/0
1m 00
Shado[ 364.177095] grsec: From 10.14.24.38: denied resource overstep by
requesting 180 for RLIMIT_CORE against limit 0 for
/bin/Application[Application:1542] uid/euid:501/501 gid/egid:501/501, parent
/bin/busybox[sh:1394] uid/euid:0/0 gid/egid:0/0
w byte legend (one shadow byte r[ 364.201006] grsec: From 10.14.24.38: denied
resource overstep by requesting 212 for RLIMIT_CORE against limit 0 for
/bin/Application[Application:1542] uid/euid:501/501 gid/egid:501/501, parent
/bin/busybox[sh:1394] uid/euid:0/0 gid/egid:0/0
[ 364.225137] grsec: more alerts, logging disabled for 10 seconds
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
Thread T10 created by T0 here:
#0 0xa35cdc1f in __interceptor_pthread_create
gcc-8.3.0/libsanitizer/asan/asan_interceptors.cc:202
#1 0x9f83d543 in
std::thread::_M_start_thread(std::unique_ptr<std::thread::_State,
std::default_delete<std::thread::_State> >, void (*)())
(/usr/lib/libstdc++.so.6+0x9c543)
#2 0x41b58ab1 (<unknown module>)
==1541==ABORTING
<<<<<
I found similar case when redhat user moved from GCC 5 to 6:
https://bugzilla.redhat.com/show_bug.cgi?id=1386445
My use case has similar characteristics in that it's very deterministic and
that the intercepted memset() thinks a local variable lives in another thread's
stack.
I'm working on trying this on gcc-9.1.0. Thanks!
More information about the Gcc-bugs
mailing list