Bug 1842745

Summary: systemd: Avoid using getauxval in nss_systemd (for static programs)
Product: [Fedora] Fedora Reporter: Andrew G. Morgan <andrew>
Component: systemdAssignee: systemd-maint
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 32CC: andrew, aoliva, arjun.is, codonell, dj, fweimer, law, lnykryn, mfabian, morgan, msekleta, pfrankli, rth, siddhesh, ssahani, s, systemd-maint, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: systemd-246-1.fc33 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-05-18 18:12:32 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Andrew G. Morgan 2020-06-02 03:13:32 UTC
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)

Comment 1 DJ Delorie 2020-06-02 03:53:58 UTC
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)

Comment 2 Florian Weimer 2020-06-02 06:18:20 UTC
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.

Comment 4 Florian Weimer 2020-06-09 13:27:27 UTC
There is now an upstream pull request which removes the use of getauxval from the NSS module.

Comment 5 Fedora Program Management 2021-04-29 16:29:16 UTC
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.

Comment 6 Zbigniew Jędrzejewski-Szmek 2021-05-18 18:12:32 UTC
This was fixed in v246, i.e. in F33. I'll not backport this to F32, sorry.

Comment 7 Andrew G. Morgan 2021-05-23 01:49:51 UTC
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.

Comment 8 Florian Weimer 2021-05-23 11:20:06 UTC
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.

Comment 9 Andrew G. Morgan 2021-05-23 15:47:38 UTC
I have filed: https://bugzilla.redhat.com/show_bug.cgi?id=1963710

Comment 10 Zbigniew Jędrzejewski-Szmek 2021-05-23 16:42:17 UTC
Oh, I thought that this is fixed because the linked pull request has been merged.

Comment 11 Florian Weimer 2021-05-23 16:59:44 UTC
(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.

Comment 12 Florian Weimer 2021-05-24 08:02:19 UTC
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.