AddressSanitizer:DEADLYSIGNAL in getaddrinfo() when compiled with clang-15 with "-nodefaultlibs" without "-lresolv" #59007
Comments
|
I can confirm this as well. Built LLVM 15.0.1 against centos7, and compiling with a shared ASan from that hitting this on centos7, Ubuntu 18.04, and Ubuntu 20.04. Ubuntu 22.04 actually does not here for me but -lresolv does fixes the issue for me on these other OS versions. |
|
The lresolv dependency seems first added with [1] 1- https://reviews.llvm.org/D126851 |
|
E.g. following patch works for me. |
|
CC @kda |
|
Let's first try to understand what happened. Here is a stack trace with some source information (with Clang 16): Let's have a look at the top frame: we call into The issue with The issue with the shared runtime seems valid however. The difference between the static and shared runtimes is that the static runtime comes with dependencies on the linker command line, whereas the shared runtime gets the dependencies from |
|
The specific issue should only occur with older glibc versions: the call to |
|
In original issue |
|
You're right, I didn't see that the original crash stack had a different caller. I also didn't see that call to |
Since the interceptor was added in 1a729bc, a process using sanitizers might need libresolv for the real version of __dn_expand. The linker flag for the static runtime was added in 6dce56b. But the dynamic runtime didn't get the dependency. This can cause crashes even when libresolv is not used directly, because it is also used by DNS lookups via e.g. getaddrinfo when the DNS reply uses compression. We observed the issue with the address sanitizer, but a quick look into the shared runtime libraries revealed that the memprof and tsan runtimes also export dn_expand and should thus be prone to the same issue. It should be mentioned that glibc plans to move libresolv into libc, which was partially completed in version 2.34 with the move of dn_comp and dn_expand. However, that is not an issue here: once the move is complete, there will only be a static libresolv.a stub left and so building against a version after the move will no longer produce a runtime dependency to libresolv.so. Fixes llvm#59007.
The functions are not relevant for most sanitizers and only required for MSan to see which regions have been written to. This eliminates a link dependency for all other sanitizers and fixes llvm#59007: while `-lresolv` had been added for the static runtime in 6dce56b, it wasn't added to the shared runtimes. Instead of just moving the interceptors, we adapt them to MSan conventions: * We don't skip intercepting when `msan_init_is_running` is true, but directly call ENSURE_MSAN_INITED() like most other interceptors. It seems unlikely that these functions are called during initialization. * We don't unpoison `errno`, because none of the functions is specified to use it.
The functions are not relevant for most sanitizers and only required for MSan to see which regions have been written to. This eliminates a link dependency for all other sanitizers and fixes llvm#59007: while `-lresolv` had been added for the static runtime in 6dce56b, it wasn't added to the shared runtimes. Instead of just moving the interceptors, we adapt them to MSan conventions: * We don't skip intercepting when `msan_init_is_running` is true, but directly call ENSURE_MSAN_INITED() like most other interceptors. It seems unlikely that these functions are called during initialization. * We don't unpoison `errno`, because none of the functions is specified to use it.
The functions are not relevant for most sanitizers and only required for MSan to see which regions have been written to. This eliminates a link dependency for all other sanitizers and fixes llvm#59007: while `-lresolv` had been added for the static runtime in 6dce56b, it wasn't added to the shared runtimes. Instead of just moving the interceptors, we adapt them to MSan conventions: * We don't skip intercepting when `msan_init_is_running` is true, but directly call ENSURE_MSAN_INITED() like most other interceptors. It seems unlikely that these functions are called during initialization. * We don't unpoison `errno`, because none of the functions is specified to use it.
EugeneZelenko
added
compiler-rt:msan
The functions are not relevant for most sanitizers and only required for MSan to see which regions have been written to. This eliminates a link dependency for all other sanitizers and fixes llvm#59007: while `-lresolv` had been added for the static runtime in 6dce56b, it wasn't added to the shared runtimes. Instead of just moving the interceptors, we adapt them to MSan conventions: * We don't skip intercepting when `msan_init_is_running` is true, but directly call ENSURE_MSAN_INITED() like most other interceptors. It seems unlikely that these functions are called during initialization. * We don't unpoison `errno`, because none of the functions is specified to use it.
The following code
compiled with
produces the following error:
If
-lresolvoption is added, it works as expected:It also works as expected if I use
clang-14instead ofclang-15.This is a very practical issue, because it is reproduced when using python's
requestsmodule with dynamically loaded sanitizer runtime (necessary when using sanitized python extensions):More info:
I posted the same bug at google/sanitizers#1592, because I am not sure if it is related to sanitizers or clang-15.
The text was updated successfully, but these errors were encountered: