diff options
| author |   Florian Weimer <fweimer@redhat.com> | 2024-06-03 10:49:40 +0200 |
|---|---|---|
| committer |   Andreas K. Hüttel <dilfridge@gentoo.org> | 2024-06-11 21:05:52 +0200 |
| commit | 92123492074290480661ca5b65997d7032291d59 (patch) | |
| tree | f92e77dca226af5a8dc5465d6014d5cad584af3c | |
| parent | x86: Properly set MINIMUM_X86_ISA_LEVEL for i386 [BZ #31867] (diff) | |
| download | glibc-92123492074290480661ca5b65997d7032291d59.tar.gz glibc-92123492074290480661ca5b65997d7032291d59.tar.bz2 glibc-92123492074290480661ca5b65997d7032291d59.zip | |
elf: Avoid some free (NULL) calls in _dl_update_slotinfo
This has been confirmed to work around some interposed mallocs. Here
is a discussion of the impact test ust/libc-wrapper/test_libc-wrapper
in lttng-tools:
New TLS usage in libgcc_s.so.1, compatibility impact
<https://inbox.sourceware.org/libc-alpha/8734v1ieke.fsf@oldenburg.str.redhat.com/>
Reportedly, this patch also papers over a similar issue when tcmalloc
2.9.1 is not compiled with -ftls-model=initial-exec. Of course the
goal really should be to compile mallocs with the initial-exec TLS
model, but this commit appears to be a useful interim workaround.
Fixes commit d2123d68275acc0f061e73d5f86ca504e0d5a344 ("elf: Fix slow
tls access after dlopen [BZ #19924]").
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
(cherry picked from commit afe42e935b3ee97bac9a7064157587777259c60e)
(cherry picked from commit 6ade91c21140d8c803c289932dbfc74537f65a1f)
| -rw-r--r-- | elf/dl-tls.c | 9 |
1 files changed, 8 insertions, 1 deletions
diff --git a/elf/dl-tls.c b/elf/dl-tls.c index 7b3dd9ab60..670dbc42fc 100644 --- a/elf/dl-tls.c +++ b/elf/dl-tls.c @@ -819,7 +819,14 @@ _dl_update_slotinfo (unsigned long int req_modid, size_t new_gen) dtv entry free it. Note: this is not AS-safe. */ /* XXX Ideally we will at some point create a memory pool. */ - free (dtv[modid].pointer.to_free); + /* Avoid calling free on a null pointer. Some mallocs + incorrectly use dynamic TLS, and depending on how the + free function was compiled, it could call + __tls_get_addr before the null pointer check in the + free implementation. Checking here papers over at + least some dynamic TLS usage by interposed mallocs. */ + if (dtv[modid].pointer.to_free != NULL) + free (dtv[modid].pointer.to_free); dtv[modid].pointer.val = TLS_DTV_UNALLOCATED; dtv[modid].pointer.to_free = NULL; |