[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal
From: |
Eli Zaretskii |
Subject: |
bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal |
Date: |
Fri, 24 Jun 2022 08:55:54 +0300 |
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: gerd.moellmann@gmail.com, 56108@debbugs.gnu.org
> Date: Thu, 23 Jun 2022 17:29:13 -0400
>
> Before `freeze_pattern`, the design was that nothing could happen while
> running the regexp matcher (no GC, no execution of Lisp code).
>
> Commit 938d252d1c6c5e2027aa250c649deb024154f936 changed that so that
> searching inside a *buffer* could end up running ELisp code (and hence
> also GC). AFAIK this still can't happen when searching in strings.
> [ IIRC The need to run ELisp is so as to apply `syntax-table` text
> properties on demand via `syntax-propertize`. ]
>
> So I think freeze_pattern should be used in all cases where
> `compile_pattern` is used to search inside a buffer, but it shouldn't be
> necessary when searching within a string.
I think at least the scenario uncovered by Gerd, shown in this
backtrace-like form:
> maybe_gc
> Ffuncall
> call2
> signal_or_quit (eval.c:1741)
> quit (eval.c:1697)
> process_quit_flag (eval.c:1657)
> probably_quit (eval.c:1864)
> maybe_quit (lisp.h:3681)
> re_match_2_internal (regexp-emacs.c:4691)
could happen even when searching within strings. And in general, as I
tried to explain up-thread, relying on what cannot happen _today_ wrt
GC is not future-proof, the way Emacs development advances.
So I think we should install a change that calls freeze_pattern for
every pattern-cache entry as long as it is in use.
Gerd, would you please show the patch for that?
- bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal, (continued)
- bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal, Gerd Möllmann, 2022/06/22
- bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal, Eli Zaretskii, 2022/06/22
- bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal, Gerd Möllmann, 2022/06/22
- bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal, Eli Zaretskii, 2022/06/22
- bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal, Gerd Möllmann, 2022/06/22
- bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal, Eli Zaretskii, 2022/06/22
- bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal, Gerd Möllmann, 2022/06/23
- bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal, Eli Zaretskii, 2022/06/23
- bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal, Eli Zaretskii, 2022/06/23
- bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal, Stefan Monnier, 2022/06/23
- bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal,
Eli Zaretskii <=
- bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal, Gerd Möllmann, 2022/06/24
- bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal, Gerd Möllmann, 2022/06/24
- bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal, Eli Zaretskii, 2022/06/24
- bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal, Eli Zaretskii, 2022/06/25
- bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal, Eli Zaretskii, 2022/06/27
- bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal, Gerd Möllmann, 2022/06/27
- bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal, Gerd Möllmann, 2022/06/23
- bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal, Eli Zaretskii, 2022/06/23
- bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal, Gerd Möllmann, 2022/06/23