Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -Wno-parentheses -Wno-format-security uname output: Linux bomb20 5.4.0-31-generic #35-Ubuntu SMP Thu May 7 20:20:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.0 Patch Level: 16 Release Status: release Description: bash crashes with a segmentation fault on the command: echo ~nosuchuser (This assumes there is no user named "nosuchuser". If there is, pick a different name). It's likely this isn't a bug in bash itself, but I haven't been able to figure out what's going on. I see this problem on copies of bash 5.0.16 and 5.0.17 built from sourced on Ubuntu 20.04 LTS. It does *not* occur with the /bin/bash GNU bash, version 5.0.16(1)-release (x86_64-pc-linux-gnu) provided by the distribution. I haven't verified how far back this goes. I built another copy of bash 5.0.16 from source with "CFLAGS=-g". When I reproduce the seg fault under gdb, I got the following traceback: [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00007ffff777eddb in ?? () from /lib/x86_64-linux-gnu/libnss_systemd.so.2 (gdb) where #0 0x00007ffff777eddb in ?? () from /lib/x86_64-linux-gnu/libnss_systemd.so.2 #1 0x00007ffff77721c8 in ?? () from /lib/x86_64-linux-gnu/libnss_systemd.so.2 #2 0x00007ffff7773009 in ?? () from /lib/x86_64-linux-gnu/libnss_systemd.so.2 #3 0x00007ffff77883e7 in _nss_systemd_getpwnam_r () from /lib/x86_64-linux-gnu/libnss_systemd.so.2 #4 0x00007ffff7e53f03 in __getpwnam_r (name=name@entry=0x555555722368 "nosuchuser", resbuf=resbuf@entry=0x7ffff7f5e140 <resbuf>, buffer=0x555555777808 "systemd-coredump", buflen=buflen@entry=1024, result=result@entry=0x7fffffffddb0) at ../nss/getXXbyYY_r.c:315 #5 0x00007ffff7e537ec in getpwnam (name=0x555555722368 "nosuchuser") at ../nss/getXXbyYY.c:134 #6 0x0000555555663dc9 in tilde_expand_word (filename=0x55555571dba8 "~nosuchuser") at ./tilde.c:386 #7 0x0000555555663a73 in tilde_expand (string=0x55555571d493 "") at ./tilde.c:234 #8 0x0000555555598456 in bash_tilde_expand (s=0x55555571d488 "~nosuchuser", assign_p=0) at general.c:1196 #9 0x00005555555d773c in expand_word_internal (word=0x55555571ffe8, quoted=0, isexp=0, contains_dollar_at=0x7fffffffe018, expanded_something=0x7fffffffe014) at subst.c:9963 #10 0x00005555555daccd in shell_expand_word_list (tlist=0x55555571d4e8, eflags=31) at subst.c:11339 #11 0x00005555555db047 in expand_word_list_internal (list=0x555555722448, eflags=31) at subst.c:11463 #12 0x00005555555da09f in expand_words (list=0x555555722448) at subst.c:10983 #13 0x00005555555a5692 in execute_simple_command (simple_command=0x5555557225c8, pipe_in=-1, pipe_out=-1, async=0, fds_to_close=0x55555571fd88) at execute_cmd.c:4323 #14 0x000055555559ee36 in execute_command_internal (command=0x555555721288, asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x55555571fd88) at execute_cmd.c:842 #15 0x000055555559e3bf in execute_command (command=0x555555721288) at execute_cmd.c:394 #16 0x0000555555586e21 in reader_loop () at eval.c:175 #17 0x00005555555846cf in main (argc=1, argv=0x7fffffffe498, env=0x7fffffffe4a8) at shell.c:805 If I understand this correctly, it died in getpwnam(). The call appears to be valid; it should simply return a null pointer. Other tests indicate that getpwnam() works correctly. (Dereferencing the null pointer could of course cause a seg fault, but the application doesn't get a chance to do that.) Repeat-By: Given that there is no user account called "nosuchuser", either: echo ~nosuchuser or bash -c 'echo ~nosuchuser'