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

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: gerd.moellmann@gmail.com,  58042@debbugs.gnu.org,  alan@idiocy.org
> Date: Wed, 05 Oct 2022 21:52:52 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.
> 
> There are many different ways to trigger redisplay from the read-socket
> hook in the Haiku port as well, and I haven't seen any problems there.
> 
> Besides, any call to automatic GC today can run arbitrary Lisp through
> finalizer functions, and that includes redisplay.  So unless the
> read_socket_hook does not cons at all, there is no way to prevent
> probably_quit from running Lisp code.

That we have other loopholes doesn't mean we shouldn't be concerned
with this one.  IMO, we should plug all those loopholes one by one.

Finalizers are very rarely used (not at all in core, I believe), so
it's a small wonder we didn't see bug reports.  As for Haiku, how man
y active users of it exist, and how "crazy" are the hooks they define
for redisplay to call?  If those hooks remain nil, nothing bad will
ever happen.