+++ This bug was initially created as a clone of Bug #2002756 +++ Description of problem: Version-Release number of selected component (if applicable): glibc-common-2.28-164.el8.x86_64 glibc-langpack-en-2.28-164.el8.x86_64 glibc-2.28-164.el8.x86_64 glibc-headers-2.28-164.el8.x86_64 glibc-devel-2.28-164.el8.x86_64 How reproducible: * always Steps to Reproduce: # dmesg -c >& /dev/null # find /usr -name vdso64.so /usr/lib/modules/4.18.0-343.el8.x86_64/vdso/vdso64.so # ldd `find /usr -name vdso64.so` ldd: exited with unknown exit code (139) # dmesg [ 190.771399] ld-linux-x86-64[5275]: segfault at 7fab7ddd9408 ip 00007fab7dbb5180 sp 00007ffd1cf21880 error 7 in ld-2.28.so[7fab7dbae000+2c000] [ 190.771408] Code: de ea 01 00 31 c0 e8 1f 96 00 00 e9 34 f4 ff ff 4c 8d 0d 9b e8 01 00 e9 c3 fb ff ff 4d 85 c0 74 71 48 8b 43 60 48 85 c0 74 04 <4c> 01 40 08 48 8b 43 58 48 85 c0 74 04 4c 01 40 08 48 8b 43 68 48 # Actual results: * segfault Expected results: * no segfault
# coredumpctl info -1 PID: 5275 (ld-linux-x86-64) UID: 0 (root) GID: 0 (root) Signal: 11 (SEGV) Timestamp: Thu 2021-09-23 15:14:19 EDT (5min ago) Command Line: /lib64/ld-linux-x86-64.so.2 --verify /usr/lib/modules/4.18.0-343.el8.x86_64/vdso/vdso64.so Executable: /usr/lib64/ld-2.28.so Control Group: /user.slice/user-0.slice/session-3.scope Unit: session-3.scope Slice: user-0.slice Session: 3 Owner UID: 0 (root) Boot ID: b3cf94a4ba904efdbdf7f81400639733 Machine ID: 4d0e3a63c207450cb7488bd9b38fda5b Hostname: rhel8-machine Storage: none Message: Process 5275 (ld-linux-x86-64) of user 0 dumped core. #
Note that the upstream patch is broken: https://sourceware.org/pipermail/libc-alpha/2021-September/131287.html I had to back it out in rawhide.
Milos, I'm evaluting this for inclusion in 8.6, but I wanted to know a little more about your requirements. Does this also impact testing in RHEL8?
From my SELinux QE point of view, it does not impact our testing at all. I found it by mistake :-)
(In reply to Milos Malik from comment #4) > From my SELinux QE point of view, it does not impact our testing at all. I > found it by mistake :-) In that case we're going to look at fixing this only for RHEL9, but it will be CLOSED/WONTFIX for RHEL8. Thanks for the report, it is helpful, and sparked a bunch of conversation around object formats :-)