http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937
Bug ID: 58937
Summary: Preloaded libasan segfaults on unsanitized executables
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: y.gribov at samsung dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
e.gavrin at samsung dot com, jakub at gcc dot gnu.org,
kcc at gcc dot gnu.org
My system has a mix of sanitized and unsanitized executables and libs calling
each other in a complex manner. I've recently tried doing a global
LD_PRELOAD=libasan to make sure I don't have problems with initialization order
outlined in #56393.
I quickly ran into a problem which is reproduced in the attach. Here is the gdb
session log:
$ /home/ygribov/install/gcc-master/bin/gcc -g main.i
$ ./a.out
$ LD_PRELOAD=~/install/gcc-master/lib64/libasan.so.0 ./a.out
Segmentation fault (core dumped)
$ gdb a.out
(gdb) set env LD_PRELOAD /home/ygribov/install/gcc-master/lib64/libasan.so.0
(gdb) b __asan_init_v1
(gdb) run
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x00007ffff4e4fa62 in signal () at
/home/ygribov/gcc/gcc-master/libsanitizer/asan/asan_interceptors.cc:133
#2 0x000000000040052c in main ()
(gdb) fr 1
#1 0x00007ffff4e4fa62 in signal () at
/home/ygribov/gcc/gcc-master/libsanitizer/asan/asan_interceptors.cc:133
133 return REAL(signal)(signum, handler);
(gdb) l
128 #endif // ASAN_INTERCEPT_PTHREAD_CREATE
129
130 #if ASAN_INTERCEPT_SIGNAL_AND_SIGACTION
131 INTERCEPTOR(void*, signal, int signum, void *handler) {
132 if (!AsanInterceptsSignal(signum)) {
133 return REAL(signal)(signum, handler);
134 }
135 return 0;
136 }
137
It seems that current libasan currently relies on sanitized code to call
__asan_init. If we preload it into an unsanitized executable, it will remain
uninitialized and will segfault on every REAL(whatever) call.
IMHO ability to do global LD_PRELOAD for all executables in the system is
rather useful so I think it makes sense to support this usage scenario. What
about adding a ctor to call __asan_init in libasan itself?
Note that this error should repro in Clang (on platforms that use dynamic
linking).
-Y
