[Bug dynamic-link/29039] New: _dl_tlsdesc_dynamic (sometimes) returns garbage offsets

["alex_y_xu at yahoo dot ca" <sourceware-bugzilla@sourceware.org>]

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

            Bug ID: 29039
           Summary: _dl_tlsdesc_dynamic (sometimes) returns garbage
                    offsets
           Product: glibc
           Version: 2.35
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: alex_y_xu at yahoo dot ca
  Target Milestone: ---

Many users have reported that Mesa 22 causes GTK4 programs to segfault on start
with the crocus driver under X. This is caused by _dl_tlsdesc_dynamic returning
a large negative value, which when added to FS results in a value slightly
above zero. Unfortunately, I have been unable to find any reduced test case,
even after testing many sequences of dlopen and dlclose calls. Additionally,
the issue reportedly does not affect Fedora Linux. The shortest reproduction
steps I have found are:

1. Use a GPU supported by the Mesa crocus driver; all i915 through Haswell
Intel GPUs should be supported.

2. podman run -it --privileged --net=host -v /tmp/.X11-unix:/tmp/.X11-unix --rm
archlinux. It may be possible to use docker instead of podman; I did not test
this. Alternatively, install Arch Linux.

3. Run:

pacman -Syu
pacman -U
https://archive.archlinux.org/packages/m/mesa/mesa-22.0.1-2-x86_64.pkg.tar.zst
pacman -S gnome-chess
useradd -m -u 1000 -g 1000 user # set to your host UID/GID
su - user
DISPLAY=:0 gnome-chess

This should segfault in lookup_opcode_desc with a small pointer dereference
which was computed in brw_opcode_desc from a call to _dl_tlsdesc_dynamic.
Unfortunately, there are no symbols for Mesa, but there are dynamic symbols for
glibc. Debug output:

$ DISPLAY=:0 gdb gnome-chess
[ ... ]
(gdb) b _dl_tlsdesc_dynamic
Breakpoint 1 at 0x7ffff7fdc600
(gdb) r
[ ... ]
Thread 1 "gnome-chess" hit Breakpoint 1, 0x00007ffff7fdc600 in
_dl_tlsdesc_dynamic () from /lib64/ld-linux-x86-64.so.2
(gdb) info reg
rax            0x7fffebe36898      140737150937240
rbx            0x7fffffff7e60      140737488322144
rcx            0x0                 0
rdx            0x7fffffff81a0      140737488322976
rsi            0x555556426d00      93825007774976
rdi            0x7fffffff8190      140737488322960
rbp            0x7fffffff8310      0x7fffffff8310
rsp            0x7fffffff7e58      0x7fffffff7e58
r8             0x5555561fec90      93825005513872
r9             0x1                 1
r10            0x7fffebb248c0      140737147717824
r11            0x91df835f16e6916b  -7935479573974183573
r12            0x5555564c0a60      93825008405088
r13            0x0                 0
r14            0x7fffffff87b0      140737488324528
r15            0x7fffffff82c0      140737488323264
rip            0x7ffff7fdc600      0x7ffff7fdc600 <_dl_tlsdesc_dynamic>
eflags         0x202               [ IF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0
(gdb) fin
Run till exit from #0  0x00007ffff7fdc600 in _dl_tlsdesc_dynamic () from
/lib64/ld-linux-x86-64.so.2
[Thread 0x7fffe9571640 (LWP 921) exited]
[Thread 0x7fffe9d72640 (LWP 920) exited]
0x00007fffeb3d8979 in ?? () from /usr/lib/dri/crocus_dri.so
(gdb) p $rax
$2 = -140737272884288
(gdb) p $rax+$fs_base
$3 = 0

Exporting LD_PRELOAD=/usr/local/lib/dri/crocus_dri.so avoids the crash, as
static TLS is used in that case. More interestingly, exporting
LD_PRELOAD=/usr/lib/libLLVM.so also avoids the crash, despite still using
dynamic TLS. Exporting LD_BIND_NOW=1 does not avoid the crash.

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