Re: bash - reproducible SEGFAULT on rapid SIGINTs

[Eduardo A . Bustamante López]

On Wed, Aug 28, 2024 at 01:16:57PM +0200, Tycho Kirchner wrote:
> Hi,
> Sending rapid SIGINTs from another shell quickly results in a SEGFAULT of the 
> bash instance receiving them. Steps to reproduce:
> * Open up a shell SHELL_1 and record its pid, e.g. "echo $$"
> * Launch another shell and send rapid SIGINTs: while true ; do kill -INT 
> OTHER_PID; done
> 
> SHELL_1 quickly dies with a SEGAULT
> 
> Tested on GNU bash, version 5.2.32(1)-release (x86_64-pc-linux-gnu), compiled 
> via plain ./configure && make
> 
> Thanks and Kind Regards
> Tycho

I am able to reproduce this as well, on the latest devel version
(2610d40b32301cd7256bf1dfc49c9f8bfe0dcd53).

The shell crashes due to what seems runaway self-recursion while handling the
interrupt signal in readline:

    $ gdb -c core ./bash -ex bt </dev/null | tail -n25
    #78489 0x0000557419f0a74e in _rl_signal_handler (sig=2) at signals.c:149
    #78490 0x0000557419f0b0f0 in _rl_release_sigint () at signals.c:674
    #78491 0x0000557419f06345 in rl_redisplay () at display.c:1671
    #78492 0x0000557419f097ed in rl_clear_message () at display.c:3154
    #78493 0x0000557419f0b06e in rl_free_line_state () at signals.c:620
    #78494 0x0000557419f0a82f in _rl_handle_signal (sig=2) at signals.c:217
    #78495 0x0000557419f0a74e in _rl_signal_handler (sig=2) at signals.c:149
    #78496 0x0000557419f0f354 in rl_getc (stream=0x7f886046a8e0 
<_IO_2_1_stdin_>) at input.c:942
    #78497 0x0000557419f0f102 in rl_read_key () at input.c:816
    #78498 0x0000557419eed750 in readline_internal_char () at readline.c:629
    #78499 0x0000557419eedb1c in readline_internal_charloop () at readline.c:737
    #78500 0x0000557419eedb3c in readline_internal () at readline.c:749
    #78501 0x0000557419eecf92 in readline (prompt=0x5574202f1c30 "bash-5.3$ ") 
at readline.c:387
    #78502 0x0000557419e2097d in yy_readline_get () at ./parse.y:1629
    #78503 0x0000557419e20a95 in yy_readline_get () at ./parse.y:1659
    #78504 0x0000557419e208ad in yy_getc () at ./parse.y:1559
    #78505 0x0000557419e21a89 in shell_getc (remove_quoted_newline=1) at 
./parse.y:2489
    #78506 0x0000557419e239e6 in read_token (command=0) at ./parse.y:3550
    #78507 0x0000557419e22cfa in yylex () at ./parse.y:3016
    #78508 0x0000557419e1d054 in yyparse () at y.tab.c:1902
    #78509 0x0000557419e1c83e in parse_command () at eval.c:365
    #78510 0x0000557419e1c933 in read_command () at eval.c:410
    #78511 0x0000557419e1c22a in reader_loop () at eval.c:143
    #78512 0x0000557419e19b8c in main (argc=1, argv=0x7ffe0622cbd8, 
env=0x7ffe0622cbe8) at shell.c:834
  
On my system, it seems to crash at around the 13k-ieth call to
_rl_signal_handler:

    $ gdb -c core ./bash -ex bt </dev/null | grep -c 0x0000557419f0a74e
    13083

This problem seems to have been introduced in Bash 4.3, in commit
ac50fbac377e32b98d2de396f016ea81e8ee9961. Prior to this change, the observable
effect on the shell which receives a flood of interrupt signals is to redisplay
the prompt, with a varying amount of empty lines in between.