Bash crashes with a segmentation fault on "trap 'kill 0' SIGTERM EXIT"

[Michael Wisheu]

Trusty's bash (4.3-7ubuntu1) crashes with a segmentation fault on the following trap statement:
trap 'kill 0' SIGTERM EXIT

Apport doesn't react to this crash and so I wasn't able to submit this bug via Apport. :-/

$ dpkg-query --show --showformat '${Package}\t${Version}\t${Architecture}\n' bash
bash 4.3-7ubuntu1 amd64

$ cat test.sh
#!/bin/bash
trap 'kill 0' SIGTERM EXIT

$ ./test.sh ; echo $?
Segmentation fault (core dumped)
139

$ gdb --args /bin/bash test.sh (with nostrip and noopt bash build)
(gdb) bt
#0 0x00007ffff761e267 in kill () at ../sysdeps/unix/syscall-template.S:81
#1 0x000000000044fbf2 in kill_pid (pid=0, sig=15, group=0) at .././jobs.c:3158
#2 0x0000000000494a09 in kill_builtin (list=0x7388a8) at ../.././builtins/../.././builtins/kill.def:186
#3 0x000000000043c7c0 in execute_builtin (builtin=0x494601 <kill_builtin>, words=0x738908, flags=0, subshell=0) at .././execute_cmd.c:4337
#4 0x000000000043d3d0 in execute_builtin_or_function (words=0x738908, builtin=0x494601 <kill_builtin>, var=0x0, redirects=0x0, fds_to_close=0x738808, flags=0)
    at .././execute_cmd.c:4758
#5 0x000000000043c271 in execute_simple_command (simple_command=0x73a0c8, pipe_in=-1, pipe_out=-1, async=0, fds_to_close=0x738808) at .././execute_cmd.c:4161
#6 0x0000000000435fe1 in execute_command_internal (command=0x73a088, asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x738808) at .././execute_cmd.c:787
#7 0x0000000000490123 in parse_and_execute (string=0x737588 "kill 0", from_file=0x4e275f "exit trap", flags=21) at ../.././builtins/evalstring.c:367
#8 0x00000000004697ef in run_exit_trap () at .././trap.c:846
#9 0x000000000041ef9e in exit_shell (s=0) at .././shell.c:915
#10 0x000000000041eacf in main (argc=2, argv=0x7fffffffdef8, env=0x7fffffffdf10) at .././shell.c:756

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Harry Willis (hwillis19)]

It's the infinite loop of trapped SIGTERMs that raises this exception, and can be performed in any way that deliberately infinitely loops a signal trap.

$ bash -c 'trap "kill 0" EXIT SIGTERM'
Segmentation fault (core dumped)

$ bash -c 'trap "kill $$" EXIT SIGTERM'
Segmentation fault (core dumped)

$ bash -c 'trap "kill 0" SIGTERM; kill 0'
Segmentation fault (core dumped)

$ bash -c 'trap "kill -USR1 $$" SIGUSR1; while :; do :; done' &
[1] 18769
$ kill -USR1 18769
[1]+ Segmentation fault (core dumped) bash -c 'trap "kill -USR1 $$" SIGUSR1; while :; do :; done'

bash_4.3-6ubuntu1 is the first version that exhibits this behaviour; versions <= bash_4.2-5ubuntu3 are not susceptible.

$ bash_4.2-5ubuntu3_amd64/bin/bash -c 'trap "echo trap; kill 0" EXIT SIGTERM'
trap
trap
trap

$ bash_4.2-5ubuntu3_amd64/bin/bash -c 'trap "echo trap; kill 0" SIGTERM; kill 0'
trap
trap

$ bash_4.3-6ubuntu1_amd64/bin/bash -c 'trap "echo trap; kill 0" EXIT SIGTERM'
trap
trap
trap
trap
[...]
trap
trap
Segmentation fault (core dumped)

[Harry Willis (hwillis19)]

So, after some browsing, it apears that trap recursion was introduced intentionally in 4.3-rc2. There is commented code in bash.c that makes it look like trap recursion was originally intended to be a configurable build option, but was made default behaviour instead.

One fairly easy fix would be to use a definable recursion limit within run_pending_traps, but I suppose we should really get a verdict on whether the plan is for recursion behaviour to stay as-is or to become a configurable option.