bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  58042@debbugs.gnu.org,  Alan Third
>  <alan@idiocy.org>
> Date: Wed, 05 Oct 2022 19:15:22 +0800
> 
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> 
> > Can somone please help me understand how this works?
> >
> > Let's say we are in memq called for list L.  Fmemq uses FOR_EACH_TAIL,
> > which can call maybe_quit, which executes arbitrary Lisp, which can
> > modify L.  And probably similarly in another 100 places.
> >
> > I don't get it.
> 
> AFAIU if it is particularly dangerous to modify L there, then input
> should be blocked around Fmemq.

How do you know whether it's "particularly dangerous"?

We call maybe_quit in many places, basically anywhere where we have
potentially long loops.  It isn't just Fmemq.  So if we want to
prevent maybe_quit from indirectly calling arbitrary Lisp, we'd need
to block_input inside probably_quit.  Which means
process_pending_signals will not call the read-socket hook and will
not gobble input.  That's bad, I think.

And note that this is only problematic on macOS (AFAIU), because there
the read-socket hook can trigger redisplay.