[Bug nptl/26955] New: pthread_key_create may return duplicates if libpthread.so loaded more than once

["sware at reimardoeffinger dot de" <sourceware-bugzilla@sourceware.org>]

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

            Bug ID: 26955
           Summary: pthread_key_create may return duplicates if
                    libpthread.so loaded more than once
           Product: glibc
           Version: 2.34
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: sware at reimardoeffinger dot de
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Created attachment 13000
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13000&action=edit
Test-case using both dlopen and dlmopen

pthread_key_create directly accesses a global variable (__pthread_keys) to scan
for a free TSS location.
This means if the library is loaded multiple times and there a multiple
instances then there will be duplicates, leading to corruption.

This can happen for example if there is a libpthread with a different name or
if dlmopen is used.

The error here is that the thread local storage allocation data structure is
associated with a specific libpthread instead of with the thread, which could
be fixed by putting a pointer to __pthread_keys into THREAD_SELF and using that
instead (alternatively, it could be partially mitigated if the values were
stored in per-library storage by pthread_setspecific, but that seems harder and
weirder).
This by itself would avoid the corruption within a single thread/in single
threaded programs at least, however if new threads are created using
pthread_create from different libpthread instances the keys would no longer be
unique across the whole process.
I believe this remaining issue could be avoided by also copying the pointer in
pthread_create (instead of setting it to the "current" libpthread's
__pthread_keys), thus distributing a pointer to the same __pthread_keys to all
threads no matter which library created them. However for that I have not
checked the code.

Note that none of this will prevent things failing completely if incompatible
versions of libpthread.so are combined, but that seems reasonable to leave out
of scope (and is likely to fail in all kinds of other ways).

Also see attached test-case. For the dlopen part to work you need to copy your
system's libpthread.so.0 to libpthread_copy.so.0 in the run directory.
The bug can be seen by the value stored in keys[0] being overwritten using
completely different keys.

This issue is the cause of e.g.
https://stackoverflow.com/questions/55008283/dlmopen-and-c-libraries/65026781#65026781
(which means that basically anything using libglib breaks very quickly when
using it with dlmopen). A test-case for that one is at
https://github.com/mhier/segregatedLinkingExample
By the comments bug 24776 seems to be a different issue, but I do not
understand all of the discussion, so possibly it is a duplicate at least in
part.

Note: I personally have not encountered this issue, but I have a use-case for
dlmopen that I need to understand the risks of. This issue getting fixed would
make it much less worrisome to rely on dlmopen.

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