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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 58042 <at> debbugs.gnu.org
Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal
Date: Sun, 25 Sep 2022 09:32:46 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: 58042 <at> debbugs.gnu.org
> Date: Sun, 25 Sep 2022 07:50:17 +0200
> 
> > The GC was triggered by
> > redisplay, but how did redisplay start while regexp match was in
> > progress?  Do you see any code in regexp that could trigger redisplay?
> 
> I'm afraid, I don't follow.  Why do you think redisplay comes into play
> here?

Because of this part of your message in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58042#8:

  freed by thread T0 here:
      #0 0x103332de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4)
      #1 0x100985e38 in rpl_free free.c:48
      #2 0x1005b71a4 in lisp_free alloc.c:1038
      #3 0x1005cbda4 in compact_small_strings alloc.c:2191
      #4 0x1005c9f24 in sweep_strings alloc.c:2072
      #5 0x1005bd028 in gc_sweep alloc.c:7397
      #6 0x1005bb178 in garbage_collect alloc.c:6245
      #7 0x1005ba694 in maybe_garbage_collect alloc.c:6090
      #8 0x1006505ac in maybe_gc lisp.h:5624
      #9 0x100648ffc in Ffuncall eval.c:2972
      #10 0x10064bcd0 in internal_condition_case_n eval.c:1555
      #11 0x1000cdc8c in safe__call xdisp.c:3026
      #12 0x1000cdfc4 in safe__call1 xdisp.c:3062
      #13 0x1001d6404 in prepare_menu_bars xdisp.c:13572
      #14 0x1000f2340 in redisplay_internal xdisp.c:16523
      #15 0x100108f34 in redisplay xdisp.c:16105

AFAIU, this says that the GC which freed the string data was caused by
safe__call1 inside prepare_menu_bars, which was called from
redisplay_internal.

> Anyways, my working hypotheses currently goes like this:
> 
> We match using some Lisp string S and get its data pointer, say D.
> Since D is not null, S must be a live string.
> 
> (Actually I didn't check that this is still the case, but I think I've
> been setting s.data to null for free strings right from the start, and I
> can't imagine why anyone would change that.)
> 
> Between the point we get D, and the point of the crash, a GC happens.
> We know in principle that a GC can happen while matching since
> bug#56108.  I'm taking that as a given.  The GC compacts strings and
> changes S's data pointer.
> 
> After GC, S.data != D.

Yes, but I have difficulty with the fact that GC was caused by
redisplay, and redisplay cannot be invoked while we are in
re_match_2_internal, AFAIK.  So something else is missing here (or
maybe I'm misinterpreting the ASAN report you posted).

Previous Next

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