From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47987 invoked by alias); 1 Apr 2015 21:42:39 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 47945 invoked by uid 48); 1 Apr 2015 21:42:35 -0000 From: "william at 25thandClement dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/18192] New: dlerror not thread-safe when libpthread loaded through dlopen Date: Wed, 01 Apr 2015 21:42:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: william at 25thandClement dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-04/txt/msg00010.txt.bz2 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.