Description of problem: When compiled statically, getpwuid(unnamed_uid), causes a program to core dump. Version-Release number of selected component (if applicable): $ rpm -q glibc glibc-2.31-2.fc32.x86_64 How reproducible: 100% Steps to Reproduce: 1. create this program: /* === bug.c === */ #include <stdio.h> #include <sys/types.h> #include <pwd.h> int main(int argc, char **argv) { printf("call for uid=1 returns: %p\n", getpwuid(1)); printf("call for uid=500 returns: %p\n", getpwuid(500)); } /* ============= */ 2. Compile it as follows: gcc --static bug.c -o bug 3. run it ./bug Actual results: $ ./bug call for uid=1 returns: 0x4bd200 Segmentation fault (core dumped) Expected results: $ ./bug call for uid=1 returns: 0x4bd200 call for uid=500 returns: (nil) Additional info: When compiling dynamically - the default - things work as intended: $ gcc bug.c -o bug $ ./bug call for uid=1 returns: 0x7fc8f7641380 call for uid=500 returns: (nil)
Reproduced. More context info... Program received signal SIGSEGV, Segmentation fault. __GI___getauxval (type=25) at getauxval.c:36 36 for (p = GLRO(dl_auxv); p->a_type != AT_NULL; p++) Missing separate debuginfos, use: dnf debuginfo-install sssd-client-2.2.3-14.fc33.x86_64 (gdb) p p $1 = (Elf64_auxv_t *) 0x0 (gdb) where #0 __GI___getauxval (type=25) at getauxval.c:36 #1 __GI___getauxval (type=type@entry=25) at getauxval.c:24 #2 0x00007ffff74a6f8e in userdb_thread_sockaddr (ret_sa=ret_sa@entry=0x7fffffffe4b0, ret_salen=ret_salen@entry=0x7fffffffe4ac) at ../src/shared/userdb.c:1252 #3 0x00007ffff74a8a35 in userdb_nss_compat_is_enabled () at ../src/shared/userdb.c:1288 #4 0x00007ffff74945a8 in userdb_getpwuid (errnop=<synthetic pointer>, buflen=1024, buffer=0x4c0bf0 "", pwd=0x4be200 <resbuf>, uid=500) at ../src/nss-systemd/userdb-glue.c:115 #5 _nss_systemd_getpwuid_r (uid=500, pwd=0x4be200 <resbuf>, buffer=0x4c0bf0 "", buflen=1024, errnop=0x4bf840) at ../src/nss-systemd/nss-systemd.c:167 #6 0x0000000000445f4b in getpwuid_r () #7 0x0000000000445cdb in getpwuid () #8 0x0000000000401d7a in main () (gdb) list 31 return GLRO(dl_hwcap); 32 else if (type == AT_HWCAP2) 33 return GLRO(dl_hwcap2); 34 35 #ifdef HAVE_AUX_VECTOR 36 for (p = GLRO(dl_auxv); p->a_type != AT_NULL; p++) 37 if (p->a_type == type) 38 return p->a_un.a_val; 39 #endif 40 (gdb)
Thanks for the backtrace. This is a known issue. At present, NSS modules cannot use getauxval, or they trigger this crash in statically linked binaries.
There is now an upstream pull request which removes the use of getauxval from the NSS module.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This was fixed in v246, i.e. in F33. I'll not backport this to F32, sorry.
I don't understand why this bug has been closed. I've upgraded to F34 and the bug, as demonstrated with the trivial program in the first entry of this bug, still fails as it did back then. (It failed in F33 before I upgraded as well). I'm also confused why a change to systemd is relevant to the static compile of glibc that this bug concerns. Thanks for clarifying.
Please obtain a new backtrace, as in comment 1. The glibc bug is fixed upstream as of last week, but I do not consider the fix backportable to Fedora 34/glibc 2.33. This means that NSS modules need to avoid getauxval for some time.
I have filed: https://bugzilla.redhat.com/show_bug.cgi?id=1963710
Oh, I thought that this is fixed because the linked pull request has been merged.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #10) > Oh, I thought that this is fixed because the linked pull request has been > merged. I expect that DJ's crash has indeed been fixed. The trigger NSS module in Andrew's crash is probably something else. Same symptoms, different causes.
The other crash comes from nss_systemd because it is linked to so many libraries. # ldd /lib64/libnss_systemd.so.2 linux-vdso.so.1 (0x00007fffc06c6000) librt.so.1 => /lib64/librt.so.1 (0x00007fe3e40b7000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fe3e408b000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fe3e4084000) libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007fe3e404a000) libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fe3e3d5c000) libp11-kit.so.0 => /lib64/libp11-kit.so.0 (0x00007fe3e3c2a000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fe3e3c0d000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe3e3bec000) libc.so.6 => /lib64/libc.so.6 (0x00007fe3e3a1d000) /lib64/ld-linux-x86-64.so.2 (0x00007fe3e4116000) libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007fe3e3986000) libz.so.1 => /lib64/libz.so.1 (0x00007fe3e396c000) libffi.so.6 => /lib64/libffi.so.6 (0x00007fe3e3961000) Zbigniew, would it be possible to avoid linking nss_systemd against libp11-kit.so.0? Thanks.