GNU bug report logs -
#58042
29.0.50; ASAN use-after-free in re_match_2_internal
Previous Next
Reported by: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Date: Sat, 24 Sep 2022 13:46:01 UTC
Severity: normal
Found in version 29.0.50
Fixed in version 29.1
Done: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: gerd.moellmann <at> gmail.com, 58042 <at> debbugs.gnu.org, alan <at> idiocy.org
> Date: Wed, 05 Oct 2022 21:52:52 +0800
>
> Eli Zaretskii <eliz <at> 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.
This bug report was last modified 2 years and 73 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.