You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Address Sanitizer fails to intercept function in shared library opened with RTLD_DEEPBIND #611
I just found out that if an application opens a shared library (both built with address sanitizer) using RTLD_DEEPBIND, address sanitizer will fail to intercept the functions called from the so opened shared library. In my particular case, this manifested itself as a strdup which, though originally skipping any interceptors and going into libc, would eventually call asan's allocator. However the same did not happen for free (since it went straight into glibc's free), so it failed to intercept free (or rather there was an allocator mismatch). I am not familiar enough with glibc to say whether this can be fixed or not, but perhaps we could drop the RTLD_DEEPBIND flag in our dlopen interceptor and issue a warning to the user.
Reacted by Liu, An-Chi, Rohak Kansal, marshall-mohror and Eugene
Interesting. I think this has no chance of working with static-libasan, so we should either remove DEEPBIND or complain about it or both. It works with -shared-libasan with clang but not with gcc, because gcc does not add DT_NEEDED for libasan to shared libraries.
Hi!
I have an environment in which I am using an external SDK. This SDK consist of a shared library I link with, and which makes use of dlopen to open other libX.so with RTLD_DEEPBIND flag. I'm not interested at all on sanitize the SDK, I only want to sanitize my own code.
How should I proceed? I'm confused about the different -shared-libasan/-static-libasan options.
As far as I understand, compiling with -static-libasan (GCC6) should inject all the sanitizer code in my binary and should have no effects on non-sanitized SDK, but I get an error on SDK trying to dlopen the .so: Couldn't load libXXX.so: System error code(-2): libXXX.so: cannot open shared object file: No such file or directory
Using LD_LIBRARY_PATH to allow the SDK finding its libXXX.so I get the famous _int_free SEGV ASAN error. Seems like the SDK is redefining any alloc/free function, so there is a mismatch on symbol resolution (SDK vs Asan).
Looks like linking with -fsanitize=address changes the order of symbols lookup/LD_PATH. I would need to isolate the SDK so it remains using libc or its own implementation (I don't know how internally works and I don't have access to source code neither).
I want this behavior #871 (comment), but I'm not able to make the SDK run when my binary is using asan.
I am open to use blacklist, suppression list, attribute((no_sanitize("address"))) or any other option, but I would like to understand the problem.
Frankly, your best choice is to contact the vendor for the SDK and request that they support asan
in whatever environment this SDK is being used.
We've seen cases in the past when a closed-source SDK did something extremely asan-hostile
and there is very little we could do there.
If you can provide a small reproducer, where you replace the SDK with a tiny mock library,
please file a separate bug and we'll take a look (but no promises, such problems are often hard to solve)
Activity
eugenis commentedon Oct 12, 2015
Interesting. I think this has no chance of working with static-libasan, so we should either remove DEEPBIND or complain about it or both. It works with -shared-libasan with clang but not with gcc, because gcc does not add DT_NEEDED for libasan to shared libraries.
kcc commentedon Oct 12, 2015
On Mon, Oct 12, 2015 at 9:30 AM, Evgeniy Stepanov notifications@github.com
wrote:
I'd say we need to complain and exit.
(We may of course, have a flag to guard the logic here, but that's on
overkill)
Don't mix RTLD_DEEPBIND and ASAN
yugr commentedon Feb 15, 2017
Does this boil down to detecting RTLD_DEEPBIND in dlopen interceptor?
kcc commentedon Feb 16, 2017
I'd guess so.
[sanitizer] Bail out with warning if user dlopens shared library with…
[sanitizer] Bail out with warning if user dlopens shared library with…
Don't mix RTLD_DEEPBIND and ASAN
Don't mix RTLD_DEEPBIND and ASAN
FerCampos commentedon Feb 26, 2018
Hi!
I have an environment in which I am using an external SDK. This SDK consist of a shared library I link with, and which makes use of dlopen to open other libX.so with RTLD_DEEPBIND flag. I'm not interested at all on sanitize the SDK, I only want to sanitize my own code.
How should I proceed? I'm confused about the different -shared-libasan/-static-libasan options.
As far as I understand, compiling with -static-libasan (GCC6) should inject all the sanitizer code in my binary and should have no effects on non-sanitized SDK, but I get an error on SDK trying to dlopen the .so:
Couldn't load libXXX.so: System error code(-2): libXXX.so: cannot open shared object file: No such file or directoryUsing LD_LIBRARY_PATH to allow the SDK finding its libXXX.so I get the famous _int_free SEGV ASAN error. Seems like the SDK is redefining any alloc/free function, so there is a mismatch on symbol resolution (SDK vs Asan).
Looks like linking with -fsanitize=address changes the order of symbols lookup/LD_PATH. I would need to isolate the SDK so it remains using libc or its own implementation (I don't know how internally works and I don't have access to source code neither).
I want this behavior #871 (comment), but I'm not able to make the SDK run when my binary is using asan.
I am open to use blacklist, suppression list, attribute((no_sanitize("address"))) or any other option, but I would like to understand the problem.
Any hints?
Thanks
kcc commentedon Mar 16, 2018
Frankly, your best choice is to contact the vendor for the SDK and request that they support asan
in whatever environment this SDK is being used.
We've seen cases in the past when a closed-source SDK did something extremely asan-hostile
and there is very little we could do there.
If you can provide a small reproducer, where you replace the SDK with a tiny mock library,
please file a separate bug and we'll take a look (but no promises, such problems are often hard to solve)
Don't mix RTLD_DEEPBIND and ASAN
Don't mix RTLD_DEEPBIND and ASAN
Don't mix RTLD_DEEPBIND and ASAN
49 remaining items
fix(ci): make ASan job build-verification only due to PHP RTLD_DEEPBI…
Fix TSAN build for integration tests (#818)
Fix TSAN build for integration tests (valkey-io#818)
fix: skip RTLD_DEEPBIND under ASAN to fix 10 plugin test failures
fix: skip RTLD_DEEPBIND under ASAN to fix 10 plugin test failures
fix: skip RTLD_DEEPBIND under ASAN to fix 10 plugin test failures
Correctly detect address sanitizer with Clang (#1712)
ci: disable opcache in the ASan job so it actually runs the suite
ci: restrict the ASan job to PHP 8.5, where it can actually run
Two open questions answered by their first CI run, and a defect found
[PT] [ASAN] Disable PT for dual ABI + ASAN (#28250)
test: add --exclude option; skip dlopen tests under ASan
Rewrite test framework, expand coverage, and fix isolation bugs (#133)
test: make the debug suite runnable at all on a sanitizer build
feat: make GPU acceleration something you get, not something you conf…