Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Address Sanitizer fails to intercept function in shared library opened with RTLD_DEEPBIND #611

Open
Keno opened this Issue Oct 11, 2015 · 6 comments

Comments

Projects
None yet
6 participants
@Keno
Copy link

Keno commented Oct 11, 2015

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.

@eugenis

This comment has been minimized.

Copy link

eugenis commented 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

This comment has been minimized.

Copy link
Contributor

kcc commented Oct 12, 2015

On Mon, Oct 12, 2015 at 9:30 AM, Evgeniy Stepanov notifications@github.com
wrote:

Interesting. I think this has no chance of working with static-libasan, so
we should either remove DEEPBIND or complain

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)

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.


Reply to this email directly or view it on GitHub
#611 (comment).

ffilz added a commit to ffilz/nfs-ganesha that referenced this issue Feb 3, 2017

Don't mix RTLD_DEEPBIND and ASAN
Due to a bug in gcc / libasan
(google/sanitizers#611), you cannot mix
RTLD_DEEPBIND and adderss sanitizing.  The result, if you do, is
allocating using ASAN and freeing using glibc, causing aborts.

If ADDRESS_SANITIZER is on, disable RTLD_DEEPBIND.

Change-Id: Ibaeaa33b7f653673f971ce3dd610d60252dbc220
Signed-off-by: Daniel Gryniewicz <dang@redhat.com>
@yugr

This comment has been minimized.

Copy link

yugr commented Feb 15, 2017

Does this boil down to detecting RTLD_DEEPBIND in dlopen interceptor?

@kcc

This comment has been minimized.

Copy link
Contributor

kcc commented Feb 16, 2017

I'd guess so.

dtzWill pushed a commit to llvm-mirror/compiler-rt that referenced this issue Mar 9, 2017

[sanitizer] Bail out with warning if user dlopens shared library with…
… RTLD_DEEPBIND flag

People keep hitting on spurious failures in malloc/free routines when using sanitizers
with shared libraries dlopened with RTLD_DEEPBIND (see google/sanitizers#611 for details).
Let's check for this flag and bail out with warning message instead of failing in random places.

Differential Revision: https://reviews.llvm.org/D30504


git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@297370 91177308-0d34-0410-b5e6-96231b3b80d8

chapuni pushed a commit to llvm-project/llvm-project that referenced this issue Mar 9, 2017

[sanitizer] Bail out with warning if user dlopens shared library with…
… RTLD_DEEPBIND flag

People keep hitting on spurious failures in malloc/free routines when using sanitizers
with shared libraries dlopened with RTLD_DEEPBIND (see google/sanitizers#611 for details).
Let's check for this flag and bail out with warning message instead of failing in random places.

Differential Revision: https://reviews.llvm.org/D30504

chapuni pushed a commit to llvm-project/llvm-project-submodule that referenced this issue Mar 9, 2017

[sanitizer] Bail out with warning if user dlopens shared library with…
… RTLD_DEEPBIND flag

People keep hitting on spurious failures in malloc/free routines when using sanitizers
with shared libraries dlopened with RTLD_DEEPBIND (see google/sanitizers#611 for details).
Let's check for this flag and bail out with warning message instead of failing in random places.

Differential Revision: https://reviews.llvm.org/D30504

jyknight pushed a commit to jyknight/llvm-monorepo-old1 that referenced this issue Mar 9, 2017

chefmax
[sanitizer] Bail out with warning if user dlopens shared library with…
… RTLD_DEEPBIND flag

People keep hitting on spurious failures in malloc/free routines when using sanitizers
with shared libraries dlopened with RTLD_DEEPBIND (see google/sanitizers#611 for details).
Let's check for this flag and bail out with warning message instead of failing in random places.

Differential Revision: https://reviews.llvm.org/D30504

llvm-svn=297370

madhuthorat added a commit to madhuthorat/nfs-ganesha that referenced this issue Nov 14, 2017

Don't mix RTLD_DEEPBIND and ASAN
Due to a bug in gcc / libasan
(google/sanitizers#611), you cannot mix
RTLD_DEEPBIND and adderss sanitizing.  The result, if you do, is
allocating using ASAN and freeing using glibc, causing aborts.

If ADDRESS_SANITIZER is on, disable RTLD_DEEPBIND.

Change-Id: Ibaeaa33b7f653673f971ce3dd610d60252dbc220
Signed-off-by: Daniel Gryniewicz <dang@redhat.com>
Signed-off-by: Madhu Thorat <madhu.punjabi@in.ibm.com>

Conflicts:
	src/include/config-h.in.cmake

madhuthorat added a commit to madhuthorat/nfs-ganesha that referenced this issue Nov 28, 2017

Don't mix RTLD_DEEPBIND and ASAN
Due to a bug in gcc / libasan
(google/sanitizers#611), you cannot mix
RTLD_DEEPBIND and adderss sanitizing.  The result, if you do, is
allocating using ASAN and freeing using glibc, causing aborts.

If ADDRESS_SANITIZER is on, disable RTLD_DEEPBIND.

Change-Id: Ibaeaa33b7f653673f971ce3dd610d60252dbc220
Signed-off-by: Daniel Gryniewicz <dang@redhat.com>
Signed-off-by: Madhu Thorat <madhu.punjabi@in.ibm.com>

Conflicts:
	src/include/config-h.in.cmake

fdo-mirror pushed a commit to freedesktop/NetworkManager that referenced this issue Jan 23, 2018

libnm-core: don't use RTLD_DEEPBIND when building with asan
The address sanitizer is not compatible [1] with libraries dynamically
opened using RTLD_DEEPBIND: disable the flag when building with asan.

[1] google/sanitizers#611

fdo-mirror pushed a commit to freedesktop/NetworkManager that referenced this issue Feb 7, 2018

libnm-core: don't use RTLD_DEEPBIND when building with asan
The address sanitizer is not compatible [1] with libraries dynamically
opened using RTLD_DEEPBIND: disable the flag when building with asan.

[1] google/sanitizers#611

fdo-mirror pushed a commit to freedesktop/NetworkManager that referenced this issue Feb 8, 2018

libnm-core: don't use RTLD_DEEPBIND when building with asan
The address sanitizer is not compatible [1] with libraries dynamically
opened using RTLD_DEEPBIND: disable the flag when building with asan.

[1] google/sanitizers#611

fdo-mirror pushed a commit to freedesktop/NetworkManager that referenced this issue Feb 8, 2018

libnm-core: don't use RTLD_DEEPBIND when building with asan
The address sanitizer is not compatible [1] with libraries dynamically
opened using RTLD_DEEPBIND: disable the flag when building with asan.

[1] google/sanitizers#611

fdo-mirror pushed a commit to freedesktop/NetworkManager that referenced this issue Feb 9, 2018

libnm-core: don't use RTLD_DEEPBIND when building with asan
The address sanitizer is not compatible [1] with libraries dynamically
opened using RTLD_DEEPBIND: disable the flag when building with asan.

[1] google/sanitizers#611

fdo-mirror pushed a commit to freedesktop/NetworkManager that referenced this issue Feb 13, 2018

libnm-core: don't use RTLD_DEEPBIND when building with asan
The address sanitizer is not compatible [1] with libraries dynamically
opened using RTLD_DEEPBIND: disable the flag when building with asan.

[1] google/sanitizers#611

fdo-mirror pushed a commit to freedesktop/NetworkManager that referenced this issue Feb 13, 2018

libnm-core: don't use RTLD_DEEPBIND when building with asan
The address sanitizer is not compatible [1] with libraries dynamically
opened using RTLD_DEEPBIND: disable the flag when building with asan.

[1] google/sanitizers#611

fdo-mirror pushed a commit to freedesktop/NetworkManager that referenced this issue Feb 15, 2018

libnm-core: don't use RTLD_DEEPBIND when building with asan
The address sanitizer is not compatible [1] with libraries dynamically
opened using RTLD_DEEPBIND: disable the flag when building with asan.

[1] google/sanitizers#611
@FerCampos

This comment has been minimized.

Copy link

FerCampos commented 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 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.

Any hints?
Thanks

@kcc

This comment has been minimized.

Copy link
Contributor

kcc commented 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)

sachinpunadikar added a commit to sachinpunadikar/nfs-ganesha that referenced this issue Nov 22, 2018

Don't mix RTLD_DEEPBIND and ASAN
Due to a bug in gcc / libasan
(google/sanitizers#611), you cannot mix
RTLD_DEEPBIND and adderss sanitizing.  The result, if you do, is
allocating using ASAN and freeing using glibc, causing aborts.

If ADDRESS_SANITIZER is on, disable RTLD_DEEPBIND.

Change-Id: Ibaeaa33b7f653673f971ce3dd610d60252dbc220
Signed-off-by: Daniel Gryniewicz <dang@redhat.com>

Conflicts:
	src/include/config-h.in.cmake

malahal pushed a commit to malahal/nfs-ganesha that referenced this issue Mar 9, 2019

Don't mix RTLD_DEEPBIND and ASAN
Due to a bug in gcc / libasan
(google/sanitizers#611), you cannot mix
RTLD_DEEPBIND and adderss sanitizing.  The result, if you do, is
allocating using ASAN and freeing using glibc, causing aborts.

If ADDRESS_SANITIZER is on, disable RTLD_DEEPBIND.

Change-Id: Ibaeaa33b7f653673f971ce3dd610d60252dbc220
Signed-off-by: Daniel Gryniewicz <dang@redhat.com>
Signed-off-by: Madhu Thorat <madhu.punjabi@in.ibm.com>

Conflicts:
	src/include/config-h.in.cmake
(cherry picked from commit 2ba269f)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
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.