[Bug libc/18034] New: [aarch64] Lazy TLSDESC relocation has data race

["nszabolcs at gmail dot com" <sourceware-bugzilla@sourceware.org>]

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

            Bug ID: 18034
           Summary: [aarch64] Lazy TLSDESC relocation has data race
           Product: glibc
           Version: 2.21
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: nszabolcs at gmail dot com
                CC: drepper.fsp at gmail dot com

With lazy TLSDESC relocation the first TLS access writes memory: the TLS
descriptor function pointer (td->entry) and its argument (td->arg), but these
writes are not synchronized with concurrent reader threads. Some threads can
observe the new entry, but not the new arg so wrong TLS offset is used by the
TLS access. All the descriptor functions must have barriers or other load-load
ordering guarantees before they access the TLSDESC argument in case of lazy
initialization.

The race is easy to trigger using a shared object that has a lot of static
TLSDESC relocations and then accessing the TLS objects from several threads.
(The bug was found by running glibc intl/tst-gettext6 test where threads access
libc internal static TLS at thread exit.)

This issue affects multi-threaded programs that access TLS through TLSDESC in a
shared object loaded with lazy binding on any architecture with "weak memory
model" (currently aarch64 and 32bit arm with -mtls-dialect=gnu2).

Lazy binding and TLSDESC are the default on aarch64 and libc.so itself does TLS
access, so essentially any multi-threaded program may crash at concurrent TLS
access (which may happen in glibc at thread exit).

(I reported this against aarch64 only because it is more critical there and the
32bit case will be easier to deal with separately once aarch64 is fixed.)

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