Seg fault on "echo ~nosuchuser"

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Seg fault on "echo ~nosuchuser"

Keith Thompson-3
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'

Reply | Threaded
Open this post in threaded view
|

Re: Seg fault on "echo ~nosuchuser"

Eric Pruitt
On Thu, May 28, 2020 at 03:12:47PM -0700, Keith Thompson wrote:
> 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.

For what it's worth, I cannot reproduce this on Bash 5.0.17 compiled
with musl 1.2.0 or glibc 2.28 on Debian 10, GCC 8.3.0.

musl:

    ~$ bash --version
    GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)
    ...
    ~$ bash -c 'echo ~nosuchuser'
    ~nosuchuser

glibc:

    bash-5.0$ ldd --version
    ldd (Debian GLIBC 2.28-10) 2.28
    ...
    bash-5.0$ ./bash --version
    GNU bash, version 5.0.17(2)-release (x86_64-pc-linux-gnu)
    ...
    bash-5.0$ ./bash -c 'echo ~nosuchuser'
    ~nosuchuser

Eric

Reply | Threaded
Open this post in threaded view
|

Re: Seg fault on "echo ~nosuchuser"

Robert Elz
In reply to this post by Keith Thompson-3
    Date:        Thu, 28 May 2020 15:12:47 -0700
    From:        Keith Thompson <[hidden email]>
    Message-ID:  <[hidden email]>


  | 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

Since that shows the crash is inside getpwnam() (or more correctly, the
NSS finctions it calls) and also shows that the correct arg was passed to
getpwnam(), it is unlikely to be a bash bug.

This one needs to be reported to whoever supplies the libc you're using,
and they will want to know what is in your nss config fle (at least the
entry for "passwd").

kre

ps: for what it is worth, this doesn't fail on NetBSD either - where I
have the NSS configured as
        passwd:         files



Reply | Threaded
Open this post in threaded view
|

Re: Seg fault on "echo ~nosuchuser"

Chet Ramey
In reply to this post by Keith Thompson-3
On 5/28/20 6:12 PM, Keith Thompson wrote:

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

Can you try this with the current devel branch head from savannah? I
have a suspicion about what's going on.

http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-devel.tar.gz

Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [hidden email]    http://tiswww.cwru.edu/~chet/

Reply | Threaded
Open this post in threaded view
|

Re: Seg fault on "echo ~nosuchuser"

Keith Thompson-3
On Fri, May 29, 2020 at 11:40 AM Chet Ramey <[hidden email]> wrote:

>
> On 5/28/20 6:12 PM, Keith Thompson wrote:
> > 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.
>
> Can you try this with the current devel branch head from savannah? I
> have a suspicion about what's going on.
>
> http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-devel.tar.gz

This did not reproduce the bug.

$ ./bash --version
GNU bash, version 5.1.0(1)-alpha (x86_64-pc-linux-gnu)
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ ./bash -c 'echo ~nosuchuser'
~nosuchuser
$

Reply | Threaded
Open this post in threaded view
|

Re: Seg fault on "echo ~nosuchuser"

Chet Ramey
On 5/29/20 2:50 PM, Keith Thompson wrote:

>> Can you try this with the current devel branch head from savannah? I
>> have a suspicion about what's going on.
>>
>> http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-devel.tar.gz
>
> This did not reproduce the bug.
>
> $ ./bash --version
> GNU bash, version 5.1.0(1)-alpha (x86_64-pc-linux-gnu)
> Copyright (C) 2020 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>
> This is free software; you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> $ ./bash -c 'echo ~nosuchuser'
> ~nosuchuser
> $

OK, that's half of it.

If you have a chance, can you verify that the problem exists with the
bash-20200520 push?

http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-ce1a3c07c4e17ed176edccd75892dfcf8242de60.tar.gz

Thanks.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [hidden email]    http://tiswww.cwru.edu/~chet/

Reply | Threaded
Open this post in threaded view
|

Re: Seg fault on "echo ~nosuchuser"

Keith Thompson-3
On Mon, Jun 1, 2020 at 6:05 AM Chet Ramey <[hidden email]> wrote:

> On 5/29/20 2:50 PM, Keith Thompson wrote:
>
> >> Can you try this with the current devel branch head from savannah? I
> >> have a suspicion about what's going on.
> >>
> >> http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-devel.tar.gz
> >
> > This did not reproduce the bug.
> >
> > $ ./bash --version
> > GNU bash, version 5.1.0(1)-alpha (x86_64-pc-linux-gnu)
> > Copyright (C) 2020 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> >
> > This is free software; you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.
> > $ ./bash -c 'echo ~nosuchuser'
> > ~nosuchuser
> > $
>
> OK, that's half of it.
>
> If you have a chance, can you verify that the problem exists with the
> bash-20200520 push?
>
>
> http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-ce1a3c07c4e17ed176edccd75892dfcf8242de60.tar.gz
>
>
Confirmed, the problem does exist with that version.
Reply | Threaded
Open this post in threaded view
|

Re: Seg fault on "echo ~nosuchuser"

Chet Ramey
On 6/1/20 3:04 PM, Keith Thompson wrote:

>     OK, that's half of it.
>
>     If you have a chance, can you verify that the problem exists with the
>     bash-20200520 push?
>
>     http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-ce1a3c07c4e17ed176edccd75892dfcf8242de60.tar.gz
>
>
> Confirmed, the problem does exist with that version.

I finally found a case where 16-byte alignment for memory returned by
malloc() is required. But it's only on Linux systems that use systemd.
I bet it's trying to marshal arguments for IPC and uses instructions
that require 16-byte alignment.

Thanks for your help verifying this.

Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [hidden email]    http://tiswww.cwru.edu/~chet/

Reply | Threaded
Open this post in threaded view
|

Re: Seg fault on "echo ~nosuchuser"

Keith Thompson-3
On Mon, Jun 1, 2020 at 12:12 PM Chet Ramey <[hidden email]> wrote:

>
> On 6/1/20 3:04 PM, Keith Thompson wrote:
>
> >     OK, that's half of it.
> >
> >     If you have a chance, can you verify that the problem exists with the
> >     bash-20200520 push?
> >
> >     http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-ce1a3c07c4e17ed176edccd75892dfcf8242de60.tar.gz
> >
> >
> > Confirmed, the problem does exist with that version.
>
> I finally found a case where 16-byte alignment for memory returned by
> malloc() is required. But it's only on Linux systems that use systemd.
> I bet it's trying to marshal arguments for IPC and uses instructions
> that require 16-byte alignment.
>
> Thanks for your help verifying this.
>
> Chet

You probably already know this, but I tested this with the last few
versions on the devel branch.

The problem occurs on versions up to and including commit
ce1a3c07c4e17ed176edccd75892dfcf8242de60 "bash-20200520 snapshot".
The problem does not occur on commit
37adc8b99d4c15dcb9e6582aa19a2ef61afb592f "bash-20200527 snapshot".

Yes, my system uses systemd.

Glad I could help.

Reply | Threaded
Open this post in threaded view
|

Re: Seg fault on "echo ~nosuchuser"

Ángel González
In reply to this post by Chet Ramey
On 2020-06-01 at 15:12 -0400, Chet Ramey wrote:
> I finally found a case where 16-byte alignment for memory returned by
> malloc() is required. But it's only on Linux systems that use systemd.
> I bet it's trying to marshal arguments for IPC and uses instructions
> that require 16-byte alignment.
>
> Thanks for your help verifying this.
>
> Chet

You mean that with systemd getpwnam() crashes if using a malloc() that
returns addresses not 16-byte aligned?

Cornercase, surely, but it seems like a bug in whatever is assuming such
alignment. That's not even pointer-size alignment.

Cheers

Reply | Threaded
Open this post in threaded view
|

Re: Seg fault on "echo ~nosuchuser"

Chet Ramey
On 6/1/20 7:58 PM, Ángel wrote:

> On 2020-06-01 at 15:12 -0400, Chet Ramey wrote:
>> I finally found a case where 16-byte alignment for memory returned by
>> malloc() is required. But it's only on Linux systems that use systemd.
>> I bet it's trying to marshal arguments for IPC and uses instructions
>> that require 16-byte alignment.
>>
>> Thanks for your help verifying this.
>>
>> Chet
>
> You mean that with systemd getpwnam() crashes if using a malloc() that
> returns addresses not 16-byte aligned?

Yes, that's what I mean. The only significant change between the bash
version that worked and the one(s) that did not is making the memory
the bash malloc returns 16-byte aligned.

Other systems not using glibc or systemd could not reproduce the issue.

> Cornercase, surely, but it seems like a bug in whatever is assuming such
> alignment. That's not even pointer-size alignment.

If systemd or its support libraries are using copy instructions that
require 16-byte alignment, though it's not documented, it's arguably not
a bug.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [hidden email]    http://tiswww.cwru.edu/~chet/