The following test fails when calling la_activity(). It is because the loader will load the audit.so modules dependencies, the libc.so will initialize its TLS static code (for the locales support), but after the audit modules loading, the loader will initialize the TLS bss with _dl_allocate_tls_init(). It will then clear the already set TLS variables from libc.so used by audit.so. $ cat audit.c #define _GNU_SOURCE #include <ctype.h> #include <link.h> volatile int out; unsigned int la_version (unsigned int v) { return LAV_CURRENT; } void la_activity (uintptr_t* cookie, unsigned int flag) { out = isspace(' '); } $ cat main.c int main (int argc, char *argv[]) { return 0; } $ gcc -Wall -fpic -shared audit.c -o audit.so $ gcc -Wall main.c -o main $ LD_AUDIT=./audit.so ./main Segmentation fault (core dumped)
Fixed in glibc 2.35 with commit 254d3d5aef2fd8430c469e1938209ac100ebf132. commit 254d3d5aef2fd8430c469e1938209ac100ebf132 Author: Adhemerval Zanella <adhemerval.zanella@linaro.org> Date: Mon Jan 24 10:46:16 2022 -0300 elf: Fix initial-exec TLS access on audit modules (BZ #28096) For audit modules and dependencies with initial-exec TLS, we can not set the initial TLS image on default loader initialization because it would already be set by the audit setup. However, subsequent thread creation would need to follow the default behaviour. This patch fixes it by setting l_auditing link_map field not only for the audit modules, but also for all its dependencies. This is used on _dl_allocate_tls_init to avoid the static TLS initialization at load time. Checked on x86_64-linux-gnu, i686-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>