[Bug dynamic-link/18192] New: dlerror not thread-safe when libpthread loaded through dlopen

[Bug dynamic-link/18192] New: dlerror not thread-safe when libpthread loaded through dlopen

[william at 25thandClement dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18192

            Bug ID: 18192
           Summary: dlerror not thread-safe when libpthread loaded through
                    dlopen
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: william at 25thandClement dot com

Created attachment 8223
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8223&action=edit
Tickle dlerror from multiple threads

__dlerror and _dlerror_run in dlfcn.h will use a shared, static buffer if
pthreads is not present when initializing internal state. And they continue
using the shared buffer even after pthreads is loaded. This can result in
double frees, NULL pointer dereferences, and other fun.

I ran into this bug via a Lua module. No Lua interpreter shipped on a major
distribution links the interpreter against libpthread.so. However, there are
many Lua modules which use pthreads and cause libpthread to be linked in via
dlopen. If dlopen/dlclose are used from multiple threads (e.g. spinning up new
Lua VMs in the threads, which will then load modules), then you can trigger
this bug. You're much more likely to encounter problems if the threads are
short-lived and the Lua interpreters unload their modules via dlclose, or if
they try to load non-existent modules.

Attached is a simple proof of concept in plain C. It loads libpthread using
dlopen("libpthread.so.0", RTLD_GLOBAL), spins up multiple threads, and from
each thread tickles dlerror by repeatedly attempting to open non-existent
libraries.

Note that Lua modules are usually loaded RTLD_LOCAL, so that might complicate
any solution.

FWIW, strsignal.c has this same problem. where_is_shmfs in shm_open.c also has
an initialization race. gaiconf_init in getaddrinfo.c might be subject to a
race, but I couldn't quickly determine which globals it accesses.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/18192] dlerror not thread-safe when libpthread loaded through dlopen

[william at 25thandClement dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18192

William Ahern <william at 25thandClement dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |william at 25thandClement dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/18192] dlerror not thread-safe when libpthread loaded through dlopen

[gabravier at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18192

Gabriel Ravier <gabravier at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gabravier at gmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/18192] dlerror not thread-safe when libpthread loaded through dlopen

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18192

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
This remains an issue only on Hurd, Linux uses an integrated libpthread since
glibc 2.34.

-- 
You are receiving this mail because:
You are on the CC list for the bug.