--- Begin Message ---
|
Subject: |
29.0.50; ASAN use-after-free in re_match_2_internal |
|
Date: |
Mon, 20 Jun 2022 16:07:55 +0200 |
FWIW, here is another non-reproducible crash with ASAN.
In short, shrink_regexp_cache realloc'd something leading to a malloc +
free, and something is still holding a pointer the old memory. Or so it
looks to me.
=22069==ERROR: AddressSanitizer: heap-use-after-free on address 0x000105b493a5
at pc 0x00010057549c bp 0x00016fde0b90 sp 0x00016fde0b88
READ of size 1 at 0x000105b493a5 thread T0
#0 0x100575498 in re_match_2_internal regex-emacs.c:5021
#1 0x100568c38 in rpl_re_search_2 regex-emacs.c:3382
#2 0x1005678c4 in rpl_re_search regex-emacs.c:3176
#3 0x10054cc68 in fast_string_match_internal search.c:489
#4 0x1004f20b0 in fast_string_match lisp.h:4747
#5 0x1004f1b28 in Ffind_file_name_handler fileio.c:324
#6 0x1004f82d4 in Fexpand_file_name fileio.c:1018
#7 0x1006ddc50 in openp lread.c:1849
#8 0x1006dae98 in Fload lread.c:1312
#9 0x1006e3c64 in save_match_data_load lread.c:1641
#10 0x1006408d0 in load_with_autoload_queue eval.c:2245
#11 0x100677534 in Frequire fns.c:3146
0x000105b493a5 is located 293 bytes inside of 558-byte region
[0x000105b49280,0x000105b494ae)
freed by thread T0 here:
#0 0x1031c7ddc in wrap_realloc+0x9c
(libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3fddc)
#1 0x100598388 in lrealloc alloc.c:1376
#2 0x1005982c4 in xrealloc alloc.c:790
#3 0x10054a490 in shrink_regexp_cache search.c:150
#4 0x1005aaeb0 in garbage_collect alloc.c:6172
#5 0x1005aa6cc in maybe_garbage_collect alloc.c:6088
#6 0x1006416c0 in maybe_gc lisp.h:5548
#7 0x10063a99c in Ffuncall eval.c:2948
#8 0x10064a144 in funcall_nil eval.c:2635
#9 0x10064a0b4 in run_hook_with_args eval.c:2812
#10 0x100649b84 in Frun_hook_with_args eval.c:2677
#11 0x100649ad0 in run_hook eval.c:2825
#12 0x1004da650 in signal_before_change insdel.c:2155
#13 0x1004d9c40 in prepare_to_modify_buffer_1 insdel.c:2009
#14 0x1004c810c in prepare_to_modify_buffer insdel.c:2020
#15 0x1005081ec in Finsert_file_contents fileio.c:4601
#16 0x10064b758 in funcall_subr eval.c:2999
#17 0x10072fa40 in exec_byte_code bytecode.c:809
#18 0x10065361c in fetch_and_exec_byte_code eval.c:3040
#19 0x10064c344 in funcall_lambda eval.c:3112
#20 0x10064ac18 in funcall_general eval.c:2903
#21 0x10063aa70 in Ffuncall eval.c:2953
#22 0x100643c0c in Fapply eval.c:2577
#23 0x10064bde0 in funcall_subr eval.c:3018
#24 0x10072fa40 in exec_byte_code bytecode.c:809
#25 0x10065361c in fetch_and_exec_byte_code eval.c:3040
#26 0x10064c344 in funcall_lambda eval.c:3112
#27 0x1006437c0 in apply_lambda eval.c:3062
#28 0x100633734 in eval_sub eval.c:2503
#29 0x100640ef8 in Feval eval.c:2314
previously allocated by thread T0 here:
#0 0x1031c7ddc in wrap_realloc+0x9c
(libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3fddc)
#1 0x100598388 in lrealloc alloc.c:1376
#2 0x1005982c4 in xrealloc alloc.c:790
#3 0x10054a490 in shrink_regexp_cache search.c:150
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal |
|
Date: |
Mon, 27 Jun 2022 16:26:02 +0300 |
> Date: Fri, 24 Jun 2022 11:35:18 +0200
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: 56108@debbugs.gnu.org
>
> Please find patch attached.
>
> Some notes about the patch:
>
> * TRT, I think, would be to change the whole cacheing to use Lisp objects
> etc. I couldn't persuade myself
> to do that.
> * A less right thing, but better than the patch, would be to protect the
> cache entry in re_match_2_internal.
> But that requires interface changes because re_match_2_internal currently
> doesn't know about cash
> entries. I couldn't bring myself to do that either.
Good points.
Since there were no more comments, I've now installed this, and I'm
marking the bug done.
P.S. Gerd, please in the future try to remember to mention the bug
number in the commit log message. (I added it this time, but I cannot
be trusted to catch that every time ;-)
--- End Message ---