[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Seg fault on "echo ~nosuchuser"

From: Keith Thompson
Subject: Seg fault on "echo ~nosuchuser"
Date: Thu, 28 May 2020 15:12:47 -0700

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

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
#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
#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
#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
#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.)

Given that there is no user account called "nosuchuser", either:

    echo ~nosuchuser


    bash -c 'echo ~nosuchuser'

reply via email to

[Prev in Thread] Current Thread [Next in Thread]