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

From: Gerd Möllmann <[email-masked]>
Date: Sun, 25 Sep 2022 09:06:59 +0200

Eli Zaretskii <[email-masked]> writes:

>       #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.

Ah, okay!  Sorry, I didn't remember that redisplay on the stack.  Please
see below.

> 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).

The second and third backtrace that ASAN displays (freed by, and
previously allocated) are not backtraces directly involved in the crash.
They display some history related to the pointer that causes the crash.

When something is allocated or freed, ASAN records callstacks that show
from where that happens.  Also, in the case pf free, it somehow arranges
that accessing that freed memory leads to a signal.  I think it uses VM
page protection for that.