[Bug dynamic-link/31717] New: TLS for library gets reallocated when loaded in two contexts.

["woodard at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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

            Bug ID: 31717
           Summary: TLS for library gets reallocated when loaded in two
                    contexts.
           Product: glibc
           Version: 2.39
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: woodard at redhat dot com
  Target Milestone: ---

Created attachment 15507
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15507&action=edit
reproducer

When a library is loaded and relocated as part of an application and it has TLS
memory that it updates and then the library is dynamically loaded with
dlopen(), the second load can change the generation counter leaving the
library's TLS area set as unallocated causing it to be reallocated the next
time that it is used. This results in any information that had been stored in
the TLS before the dlopen() of the library being lost.

This problem was reported by a customer when using libomp and librocprofiler
and in that case libomp loses the mappings to its threads.

This problem seems to have existed for quite some time. I have verified that it
exists as far back as glibc-2.28 in RHEL8 and it still exists in the latest
glibc-2.39 found in rawhide. In other words it seems like practically all
versions of glibc are affected. 

The sequence of operations is as follows:

    Libraries A and B are loaded and relocated
    A's init constructor is called:
        Inside, A calls a function that resolves to B
        B accesses and alters its TLS
    B is then dlopen()'d by "C" (which may be A or B or neither)
        Inside, Glibc advances the generation counter and marks B's TLS as
"unallocated"
    B accesses its TLS again, changes from before are lost

In the failing case (audit + rocprof), B is libhpcrun.so, A is libomp.so and
"C" is librocprofiler.so. In the suspicious case (no audit + rocprof), B is
libomp.so, and A and "C" are libomptarget.so.

Sometimes this bug is masked by the fact that B's TLS is a static block and so
even though its TLS gets "reallocated" in the middle it gets the same memory
back and it isn't reinitialized in between, so it looks like nothing happened.
In other cases, the library whose TLS gets reallocated is written robustly
enough that it simply reinitializes its TLS data and the only apparent effect
is a loss of allocated memory.

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