Bug#948287: bash: *** stack smashing detected *** ( SIGABRT crash )
Dear Maintainer, encountered again such a crash of a bash that was started while the old libc6 was installed, then installed a libc6 update, and then the "old" bash crashed after a tab completion. libc6:amd64 (2.30-8, 2.31-3) bash:amd64 (5.0-6, 5.0-7) Kind regards, Bernhard $ cp log*** stack smashing detected ***: terminated Connection to ... closed. # coredumpctl gdb PID: 4738 (bash) UID: 1000 (benutzer) GID: 1000 (benutzer) Signal: 6 (ABRT) Timestamp: Fri 2020-08-14 17:50:14 CEST (37s ago) Command Line: -bash Executable: /usr/bin/bash Stack trace of thread 4738: #0 0x7f4c0d38e781 n/a (/usr/lib/x86_64-linux-gnu/libc-2.30.so (deleted) + 0x3b781) #1 0x7f4c0d45fd7d n/a (/usr/lib/x86_64-linux-gnu/libc-2.30.so (deleted) + 0x10cd7d)
Bug#948287: bash: *** stack smashing detected *** ( SIGABRT crash )
Control: reassign -1 libc6 2.29-9 Control: affects -1 bash Dear Maintainer, reassigning to get hold of libc6 maintainer about the issue of incompatible tunables indices between libc6 versions. Therefore applications could crash when libc is from previous package version, then a package update gets installed, and then libpthread is from new version is loaded. Kind regards, Bernhard
Bug#948287: bash: *** stack smashing detected *** ( SIGABRT crash )
Dear Maintainer,
today I received this stack smashing also in one of my VMs.
I could reproduce the isse when ever a bash is started
while 2.29-7 got started and left open.
Then in a different shell the packages get upgraded,
especially glibc packages to version 2.29-9.
Then get back to the opened shell before and I could good
reproduce it by "dpkg-deb -x g".
As far as I could follow it, then libpthread-2.29.so gets loaded,
but the version 2.29-9 while libc-2.29.so is still 2.29-7.
Then the stack canary from __pthread_tunables_init gets overwritten here:
Old value = 898596864
New value = 0
__GI___tunable_get_val (id=, valp=,
callback=) at dl-tunables.c:393
393 dl-tunables.c: Datei oder Verzeichnis nicht gefunden.
1: x/i $pc
=> 0x7f42d1904cc3 <__GI___tunable_get_val+99>: jmp0x7f42d1904c8d
<__GI___tunable_get_val+45>
(gdb) bt
#0 __GI___tunable_get_val (id=, valp=,
callback=) at dl-tunables.c:393
#1 0x7f42d137206a in __pthread_tunables_init () at
pthread_mutex_conf.c:43
#2 0x7f42d1364bdd in __pthread_initialize_minimal_internal () at
nptl-init.c:437
#3 0x7f42d1364009 in _init () at ../sysdeps/x86_64/crti.S:74
#4 0x in ?? ()
https://sources.debian.org/src/glibc/2.29-9/nptl/pthread_mutex_conf.c/#L43
(gdb) print (int)glibc_pthread_mutex_spin_count
$6 = 23
(gdb) print tunable_list[23]
$7 = {name = 0x7f42d190ecc3 "glibc.malloc.tcache_max", type = {type_code =
TUNABLE_TYPE_SIZE_T, min = 0, max = -1}, val = {numval = 0, strval = 0x0},
initialized = false, security_level = TUNABLE_SECLEVEL_SXID_ERASE, env_alias =
0x0}
(gdb) print tunable_list[22]
$8 = {name = 0x7f42d19112b0 "glibc.pthread.mutex_spin_count", type =
{type_code = TUNABLE_TYPE_INT_32, min = 0, max = 32767}, val = {numval = 100,
strval = 0x64 }, initialized =
false, security_level = TUNABLE_SECLEVEL_SXID_ERASE, env_alias = 0x0}
It looks like between 2.29-7 and 2.29-9 the position in
the tunable_list array shifted and now libpthread accesses
element 23 while there is a different, bigger sized value
which leads to overwriting the stack canary.
I guess the question now is if this is a supported szenario?
If yes this bug needs to be handled by glibc maintainers?
A workaround in bash could be to make sure to have
libpthread loaded at startup, that way also holding
the same (outdated) version in memory.
Kind regards,
Bernhard
# Bullseye/testing amd64 qemu VM 2020-01-29
apt update
apt dist-upgrade
apt install systemd-coredump mc fakeroot
apt build-dep grub-efi-ia32
# not yet rebooted
benutzer@debian:~/deb$ dpkg-dev -x gr*** stack smashing detected ***:
terminated
Connection to 127.0.254.63 closed.
root@debian:~# journalctl --no-pager
-- Logs begin at Wed 2020-01-29 15:24:56 CET, end at Wed 2020-01-29 15:29:14
CET. --
Jan 29 15:24:56 debian kernel: Linux version 5.3.0-3-amd64
(debian-ker...@lists.debian.org) (gcc version 9.2.1 20191130 (Debian 9.2.1-21))
#1 SMP Debian 5.3.15-1 (2019-12-07)
...
Jan 29 15:29:14 debian systemd-coredump[23763]: Process 1008 (bash) of user
1000 dumped core.
Stack trace of thread 1008:
#0 0x7f7060d8b081 n/a
(/usr/lib/x86_64-linux-gnu/libc-2.29.so (deleted) + 0x3a081)
#1 0x7f7060e5b81d n/a
(/usr/lib/x86_64-linux-gnu/libc-2.29.so (deleted) + 0x10a81d)
Jan 29 15:29:14 debian systemd[1]: systemd-coredump@0-23762-0.service:
Succeeded.
root@debian:~# coredumpctl list
TIMEPID UID GID SIG COREFILE EXE
Wed 2020-01-29 15:29:14 CET1008 1000 1000 6 present /usr/bin/bash
root@debian:~# coredumpctl gdb 1008
PID: 1008 (bash)
UID: 1000 (benutzer)
GID: 1000 (benutzer)
Signal: 6 (ABRT)
Timestamp: Wed 2020-01-29 15:29:14 CET (4min 0s ago)
Command Line: -bash
Executable: /usr/bin/bash
Control Group: /user.slice/user-1000.slice/session-3.scope
Unit: session-3.scope
Slice: user-1000.slice
Session: 3
Owner UID: 1000 (benutzer)
Boot ID: 40d7405f80194b29af2d13741d10b59a
Machine ID: 33f18f39d2a9438eb75b0ed52848afcd
Hostname: debian
Storage:
/var/lib/systemd/coredump/core.bash.1000.40d7405f80194b29af2d13741d10b59a.1008.1580308154.lz4
Message: Process 1008 (bash) of user 1000 dumped core.
Stack trace of thread 1008:
#0 0x7f7060d8b081 n/a
(/usr/lib/x86_64-linux-gnu/libc-2.29.so (deleted) + 0x3a081)
#1 0x7f7060e5b81d n/a
(/usr/lib/x86_64-linux-gnu/libc-2.29.so (deleted) + 0x10a81d)
GNU gdb (Debian 8.3.1-1) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
Bug#948287: bash: *** stack smashing detected *** ( SIGABRT crash )
Am 09.01.20 um 17:56 schrieb crvi c: > I am using the same bash / gnome-terminal as part of my daily work. The > crash was random and it is not consistently reproducible. I have a > couple of bash core files, if that would be of any help. Ok, I see - had hoped it to be better reproducible. In my tests I found that the function in question get executed if I do for example "ls /" and tab. Could be the crashing cases are related to absolute paths? Otherwise you could try to run it by valgrind e.g. like following: valgrind --tool=memcheck--trace-children=no --child-silent-after-fork=yes bash valgrind --tool=exp-sgcheck --trace-children=no --child-silent-after-fork=yes bash Another approach could be, if CPU support is given, to use a timetravel debugger like rr to record bash executions and replay a crashing one to find out where the stack canary got overwritten. Unfortunately a core did alreay run over the interesting instruction changing that stack canary, will therefore not of so much use. Maybe just if the stack would be overwritten with some recognizable values ... Kind regards, Bernhard
Bug#948287: bash: *** stack smashing detected *** ( SIGABRT crash )
On Thu, 9 Jan 2020 at 21:53, Bernhard Übelacker wrote: > Am 09.01.20 um 17:05 schrieb crvi c: > > gdb -q -batch -command ~/gdb-cmds.bash.txt --args bash > > Function "__pthread_tunables_init" not defined. > > Breakpoint 1 (__pthread_tunables_init) pending. > > [Detaching after fork from child process 37973] > > Sorry, wasn't clear about that. > The prompt then shown should belong to the bash being debugged, > have tried to trigger the crash in that prompt again? > I am using the same bash / gnome-terminal as part of my daily work. The crash was random and it is not consistently reproducible. I have a couple of bash core files, if that would be of any help. > Kind regards, > Bernhard >
Bug#948287: bash: *** stack smashing detected *** ( SIGABRT crash )
Am 09.01.20 um 17:05 schrieb crvi c: > gdb -q -batch -command ~/gdb-cmds.bash.txt --args bash > Function "__pthread_tunables_init" not defined. > Breakpoint 1 (__pthread_tunables_init) pending. > [Detaching after fork from child process 37973] Sorry, wasn't clear about that. The prompt then shown should belong to the bash being debugged, have tried to trigger the crash in that prompt again? Kind regards, Bernhard
Bug#948287: bash: *** stack smashing detected *** ( SIGABRT crash )
On Tue, 7 Jan 2020 at 21:32, Bernhard Übelacker wrote: > Hello crvi c, > could you please add an example command > that you want to have completed? > > cd libdmapsharing I did cd libd and bash crashed. > And if you have changed the environment GLIBC_TUNABLES, > to which value? > > Nope. > Otherwise a gdb session driven by the two commands below > could maybe point to the exact location where the overwriting > takes place, if watchpoint 5 is reached, and we assume > that __pthread_tunables_init is just called once... > > Kind regards, > Bernhard > > > cat < /tmp/gdb-cmd.txt > set width 0 > set pagination off > display/i \$pc > set breakpoint pending on > b __pthread_tunables_init > run > dele 1 > b * (__pthread_tunables_init+30) > cont > dele 2 > disassemble __pthread_tunables_init, __pthread_tunables_init+70 > print/x \$rax > print/x \$rsp + 0x8 > print/x *(long*) \$2 > bt > b * (__pthread_tunables_init+37) > cont > dele 3 > print/x *(long*) \$2 > b * (__pthread_tunables_init+56) > watch *(long*) \$2 > cont > info b > bt full > disa 4 > disa 5 > cont > bt > quit > EOF > > gdb -q -batch -command /tmp/gdb-cmd.txt --args bash > gdb -q -batch -command ~/gdb-cmds.bash.txt --args bash Function "__pthread_tunables_init" not defined. Breakpoint 1 (__pthread_tunables_init) pending. [Detaching after fork from child process 37973]
Bug#948287: bash: *** stack smashing detected *** ( SIGABRT crash )
Hello crvi c, could you please add an example command that you want to have completed? And if you have changed the environment GLIBC_TUNABLES, to which value? Otherwise a gdb session driven by the two commands below could maybe point to the exact location where the overwriting takes place, if watchpoint 5 is reached, and we assume that __pthread_tunables_init is just called once... Kind regards, Bernhard cat < /tmp/gdb-cmd.txt set width 0 set pagination off display/i \$pc set breakpoint pending on b __pthread_tunables_init run dele 1 b * (__pthread_tunables_init+30) cont dele 2 disassemble __pthread_tunables_init, __pthread_tunables_init+70 print/x \$rax print/x \$rsp + 0x8 print/x *(long*) \$2 bt b * (__pthread_tunables_init+37) cont dele 3 print/x *(long*) \$2 b * (__pthread_tunables_init+56) watch *(long*) \$2 cont info b bt full disa 4 disa 5 cont bt quit EOF gdb -q -batch -command /tmp/gdb-cmd.txt --args bash
Bug#948287: bash: *** stack smashing detected *** ( SIGABRT crash )
Package: bash
Version: 5.0-5
Severity: important
Tags: upstream
Dear Maintainer,
* What led up to the situation?
bash TAB autocompletion
* What exactly did you do (or not do) that was effective (or
ineffective)?
bash tab autocompletion crashes with *** stack smashing detected ***
* What was the outcome of this action?
crash
* What outcome did you expect instead?
no crash
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.4.0-1-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages bash depends on:
ii base-files 11
ii debianutils 4.9.1
ii libc62.29-8
ii libtinfo66.1+20191019-1
Versions of packages bash recommends:
ii bash-completion 1:2.9-1
Versions of packages bash suggests:
pn bash-doc
-- Configuration Files:
/etc/bash.bashrc changed:
[ -z "$PS1" ] && return
shopt -s checkwinsize
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
if ! [ -n "${SUDO_USER}" -a -n "${SUDO_PS1}" ]; then
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
if [ -x /usr/lib/command-not-found -o -x
/usr/share/command-not-found/command-not-found ]; then
function command_not_found_handle {
# check because c-n-f could've been removed in the meantime
if [ -x /usr/lib/command-not-found ]; then
/usr/lib/command-not-found -- "$1"
return $?
elif [ -x /usr/share/command-not-found/command-not-found ]; then
/usr/share/command-not-found/command-not-found -- "$1"
return $?
else
printf "%s: command not found\n" "$1" >&2
return 127
fi
}
fi
ulimit -c unlimited
-- no debconf information
