GNU bug report logs - #58042
29.0.50; ASAN use-after-free in re_match_2_internal

Previous Next

Full log

Message #143 received at 58042 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: gerd.moellmann <at> gmail.com, alan <at> idiocy.org, 58042 <at> debbugs.gnu.org
Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal
Date: Wed, 05 Oct 2022 16:37:35 +0300

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  58042 <at> debbugs.gnu.org,  Alan Third
>  <alan <at> idiocy.org>
> Date: Wed, 05 Oct 2022 19:15:22 +0800
> 
> Gerd Möllmann <gerd.moellmann <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.