Re: use-after-free in rl_display_match_list

[Chet Ramey]

On 3/22/23 12:06 PM, Grisha Levit wrote:
> On Wed, Mar 22, 2023 at 11:50 AM Chet Ramey <chet.ramey@case.edu> wrote:
> > Thanks for the report. It's the unusual application that receives a SIGINT
> > and doesn't at least jump back to the top level.
>
> I might be misunderstanding, but I was only testing with bash, not any
> other application.

I can't reproduce it with bash and command completion (that's the easiest
way to get more possible completions than the completion-query-items
limit) or filename completion on /usr/bin. This is on RHEL 9 without any
completions installed. It jumps back to PS1.

The call chain (current devel branch version) goes something like this:

get_y_or_n
rl_getc
pselect
        SIGINT -> _rl_caught_signal = SIGINT -> pselect returns -1
back to rl_getc
        RL_CHECK_SIGNALS
_rl_signal_handler -> _rl_handle_signal (SIGINT)
        _rl_complete_sigcleanup -- this is where `matches' gets freed
        [some other signal cleanup code]
        [restore application signal handler]
        kill (0, SIGINT)
sigint_sighandler (bash)
        [bash signal cleanup code]
        bashline_set_event_hook -> rl_signal_event_hook = bash_event_hook
back to _rl_handle_signal
        [more cleanup code, returns from RL_CHECK_SIGNALS]
back to rl_getc
rl_getc calls bash_event_hook through rl_signal_event_hook
bash_event_hook calls check_signals_and_traps
throw_to_top_level -> longjmp(top_level)
reader_loop, which starts the whole readline() call chain again

There's a lot of work to avoid doing too much in signal handlers. There
have been changes since bash-5.2 was released, but I wasn't able to
reproduce it with bash-5.2.15, either.

Your change is reasonable, and I installed it, but I wasn't able to do
any before-and-after checking.

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