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

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>> ==79227==ERROR: AddressSanitizer: heap-use-after-free on address 0x00011f81e7d1 at pc 0x0001005825c4 bp 0x00016fdcf370 sp 0x00016fdcf368
>> READ of size 1 at 0x00011f81e7d1 thread T0
>>     #0 0x1005825c0 in re_match_2_internal regex-emacs.c:4352
>>     #1 0x10057e5cc in rpl_re_search_2 regex-emacs.c:3383
>>     #2 0x10057d1c4 in rpl_re_search regex-emacs.c:3177
>>     #3 0x10056115c in fast_string_match_internal search.c:492
>>     #4 0x1005045c0 in fast_string_match lisp.h:4818
>>     #5 0x100504018 in Ffind_file_name_handler fileio.c:324
>>     #6 0x1006dbe5c in openp lread.c:1911
>>     #7 0x1006d8844 in Fload lread.c:1302
>>     #8 0x1006e1af0 in save_match_data_load lread.c:1630
>>     #9 0x10064f8cc in load_with_autoload_queue eval.c:2269
>>     #10 0x10067d2f8 in Frequire fns.c:3274

Here's a guess:

Suppose that strings a compacted in a GC happening between
fast_string_match and re_match_2_internal.  That GC compacts strings,
moves the data of the string being matched from one block to another,
and the block where the string data used to be is freed.

Then the char* used in the regexp machine point into no-man's-land.