[Bug nptl/17621] New: DTV update for Static TLS dlopened modules is racy

["aoliva at sourceware dot org" <sourceware-bugzilla@sourceware.org>]

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

            Bug ID: 17621
           Summary: DTV update for Static TLS dlopened modules is racy
           Product: glibc
           Version: 2.21
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: aoliva at sourceware dot org
          Reporter: aoliva at sourceware dot org
                CC: drepper.fsp at gmail dot com

When we dlopen a module whose TLS segment is assigned to Static TLS, we not
only initialize every thread's Static TLS area, but also (with nptl) the
corresponding DTV entry.

While nobody could possibly be using the Static TLS range concurrently, it
doesn't ever move, and some synchronization between the dlopened thread and
other threads that use the initialized TLS area is required for the TLS uses to
be well-defined, the DTV entry might be updated concurrently, if its owner
thread finds it was out of date and it held non-Static TLS in earlier
generations, and it might even be resized and moved during update, causing the
initialization performed by the dlopen-running thread to write to memory that
may have already been already copied, losing the update or, worse, that may
have been repurposed, causing memory corruption.

Fortunately, we don't resize DTVs very often, and even if the update is lost,
dlopened modules referenced with IE don't depend on the DTV at all, and
variables accessed with IE tend to be accessed with IE by all their users (most
often, the only user is the defining module itself).

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