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

Previous Next

Package: emacs;

Reported by: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Date: Sat, 24 Sep 2022 13:46:01 UTC

Severity: normal

Found in version 29.0.50

Fixed in version 29.1

Done: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Bug is archived. No further changes may be made.

Full log

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Po Lu <luangruo <at> yahoo.com>, Alan Third <alan <at> idiocy.org>,
 58042 <at> debbugs.gnu.org
Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal 
Date: Wed, 05 Oct 2022 12:45:04 +0200

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

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>> So I guess we should do this dance around calls to maybe_quit in
>>> regex-emacs.c:
>>>
>>>   specpdl_ref gc_count = inhibit_garbage_collection ();
>>>   maybe_quit ();
>>>   unbind_to (gc_count, Qnil);
>>>
>>> Or maybe even better, do this inside probably_quit (because who knows
>>> how many other callers of maybe_quit could be hit by this unexpected
>>> GC)?
>>>
>>> Can you try this?
>>
>> Isn't the -[EmacsView layoutSublayersOfLayer:] the problem?  AFAICT from
>> a web search, this is an event handler method that is also called from
>> by the framework?
>>
>> In the olden days, it was a serious error to call into Lisp from an
>> event handler.  All bets were off when that happened, not only related
>> to GC.  I believe that hasn't changed much.
>>
>> That code was introduced by Alan around this time.
>>
>> 1ba02d85a964e1b2c6a9735cd3decdc524e06dc1
>> Author:     Alan Third <alan <at> idiocy.org>
>> AuthorDate: Sat Jun 12 10:25:47 2021 +0100
>> Commit:     Alan Third <alan <at> idiocy.org>
>> CommitDate: Sat Jul 31 11:13:05 2021 +0100
>>
>> Maybe Allen can say something, I've CC'd him.
>>
>> Or maybe we should add your fix, too?
>
> And a similar question to Po Lu because of
>
> f81065a91be5a54b78e202df6918aff443588ae1
> Author:     Po Lu <luangruo <at> yahoo.com>
> AuthorDate: Mon May 30 16:03:11 2022 +0800
> Commit:     Po Lu <luangruo <at> yahoo.com>
> CommitDate: Mon May 30 16:03:11 2022 +0800
>
> which added a call to redisplay to - (NSDragOperation) draggingUpdated:
> (id <NSDraggingInfo>) sender.  Is that safe here?

And an update to the second ASAN error that I could actually reproduce
by starting Emacs on my branch:

==64010==ERROR: AddressSanitizer: heap-use-after-free on address 0x000107130d00 at pc 0x0001002a48d8 bp 0x00016fdcaa80 sp 0x00016fdcaa78
READ of size 8 at 0x000107130d00 thread T0
    #0 0x1002a48d4 in PSEUDOVECTORP lisp.h:1110
    #1 0x1002a4944 in SYMBOL_WITH_POS_P lisp.h:1122
    #2 0x10025a3f4 in EQ lisp.h:1342
    #3 0x100280f6c in run_window_change_functions window.c:3964
    #4 0x1000f1980 in redisplay_internal xdisp.c:16600
    #5 0x100107cb4 in redisplay xdisp.c:16111
    #6 0x10089364c in -[EmacsView layoutSublayersOfLayer:] nsterm.m:8661
    #7 0x1900a9624 in CA::Layer::layout_if_needed(CA::Transaction*)+0x224 (QuartzCore:arm64e+0x20624)
    #8 0x1901f661c in CA::Context::commit_transaction(CA::Transaction*, double, double*)+0x1c0 (QuartzCore:arm64e+0x16d61c)
    #9 0x19008b4c8 in CA::Transaction::commit()+0x2bc (QuartzCore:arm64e+0x24c8)
    #10 0x18bee1698 in __62+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink]_block_invoke+0x12c (AppKit:arm64e+0x1ac698)
    #11 0x18c646754 in ___NSRunLoopObserverCreateWithHandler_block_invoke+0x3c (AppKit:arm64e+0x911754)
    #12 0x1892101a0 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__+0x20 (CoreFoundation:arm64e+0x841a0)
    #13 0x18920fff0 in __CFRunLoopDoObservers+0x24c (CoreFoundation:arm64e+0x83ff0)
    #14 0x18920f524 in __CFRunLoopRun+0x300 (CoreFoundation:arm64e+0x83524)
    #15 0x18920ea80 in CFRunLoopRunSpecific+0x254 (CoreFoundation:arm64e+0x82a80)
    #16 0x191e4e334 in RunCurrentEventLoopInMode+0x120 (HIToolbox:arm64e+0x32334)
    #17 0x191e4dfc0 in ReceiveNextEventCommon+0x140 (HIToolbox:arm64e+0x31fc0)
    #18 0x191e4de64 in _BlockUntilNextEventMatchingListInModeWithFilter+0x44 (HIToolbox:arm64e+0x31e64)
    #19 0x18bd76518 in _DPSNextEvent+0x358 (AppKit:arm64e+0x41518)
    #20 0x18bd74e10 in -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]+0x52c (AppKit:arm64e+0x3fe10)
    #21 0x18bd66fdc in -[NSApplication run]+0x250 (AppKit:arm64e+0x31fdc)
    #22 0x100870bb0 in -[EmacsApp run] nsterm.m:5799
    #23 0x1008c7b0c in ns_read_socket_1 nsterm.m:4679
    #24 0x1008ae530 in ns_read_socket nsterm.m:4697
    #25 0x100437168 in gobble_input keyboard.c:7379
    #26 0x1004389d0 in handle_async_input keyboard.c:7610
    #27 0x1004389b0 in process_pending_signals keyboard.c:7624
    #28 0x100438acc in unblock_input_to keyboard.c:7639
    #29 0x100432cac in unblock_input keyboard.c:7658
    #30 0x1005ba024 in garbage_collect alloc.c:6256
    #31 0x1005b950c in maybe_garbage_collect alloc.c:6090
    #32 0x10064f6a8 in maybe_gc lisp.h:5622
    #33 0x10063fcfc in eval_sub eval.c:2388
    #34 0x100640838 in eval_sub eval.c:2449
    #35 0x10064234c in Fprogn eval.c:436
    #36 0x100654eb8 in funcall_lambda eval.c:3218
    #37 0x1006532c4 in funcall_general eval.c:2941
    #38 0x100647fcc in Ffuncall eval.c:2979
    #39 0x100651ca8 in Fapply eval.c:2650
    #40 0x10063ead8 in apply1 eval.c:2866
    #41 0x1006484bc in Fmacroexpand eval.c:1149
    #42 0x10065394c in funcall_subr eval.c:3019
    #43 0x10072e004 in exec_byte_code bytecode.c:809
    #44 0x10065c16c in fetch_and_exec_byte_code eval.c:3066
    #45 0x100654994 in funcall_lambda eval.c:3138
    #46 0x10065316c in funcall_general eval.c:2929
    #47 0x100647fcc in Ffuncall eval.c:2979
    #48 0x1006fcd80 in call2 lisp.h:3302
    #49 0x1006f4ecc in readevalloop_eager_expand_eval lread.c:2151
    #50 0x1006e0b0c in readevalloop lread.c:2343
    #51 0x1006e236c in Feval_buffer lread.c:2416
    #52 0x100653d24 in funcall_subr eval.c:3025
    #53 0x10072e004 in exec_byte_code bytecode.c:809
    #54 0x10065c16c in fetch_and_exec_byte_code eval.c:3066
    #55 0x100654994 in funcall_lambda eval.c:3138
    #56 0x10065316c in funcall_general eval.c:2929
    #57 0x100647fcc in Ffuncall eval.c:2979
    #58 0x1006ddfe8 in call4 lisp.h:3317
    #59 0x1006d9058 in Fload lread.c:1483
    #60 0x1006e1158 in save_match_data_load lread.c:1636
    #61 0x10064e9c8 in load_with_autoload_queue eval.c:2271
    #62 0x10067cb40 in Frequire fns.c:3308
    #63 0x100653a54 in funcall_subr eval.c:3021
    #64 0x10072e004 in exec_byte_code bytecode.c:809
    #65 0x10065c16c in fetch_and_exec_byte_code eval.c:3066
    #66 0x100654994 in funcall_lambda eval.c:3138
    #67 0x10065316c in funcall_general eval.c:2929
    #68 0x100647fcc in Ffuncall eval.c:2979
    #69 0x100651ca8 in Fapply eval.c:2650
    #70 0x100654414 in funcall_subr eval.c:3044
    #71 0x10072e004 in exec_byte_code bytecode.c:809
    #72 0x10065c16c in fetch_and_exec_byte_code eval.c:3066
    #73 0x100654994 in funcall_lambda eval.c:3138
    #74 0x100650834 in apply_lambda eval.c:3088
    #75 0x100641734 in eval_sub eval.c:2529
    #76 0x1006f5394 in readevalloop_eager_expand_eval lread.c:2160
    #77 0x1006e0b0c in readevalloop lread.c:2343
    #78 0x1006e236c in Feval_buffer lread.c:2416
    #79 0x100653d24 in funcall_subr eval.c:3025
    #80 0x10072e004 in exec_byte_code bytecode.c:809
    #81 0x10065c16c in fetch_and_exec_byte_code eval.c:3066
    #82 0x100654994 in funcall_lambda eval.c:3138
    #83 0x10065316c in funcall_general eval.c:2929
    #84 0x100647fcc in Ffuncall eval.c:2979
    #85 0x1006ddfe8 in call4 lisp.h:3317
    #86 0x1006d9058 in Fload lread.c:1483
    #87 0x1006410e8 in eval_sub eval.c:2496
    #88 0x10064234c in Fprogn eval.c:436
    #89 0x100646c90 in Flet eval.c:1023
    #90 0x1006403e0 in eval_sub eval.c:2435
    #91 0x10064234c in Fprogn eval.c:436
    #92 0x100654eb8 in funcall_lambda eval.c:3218
    #93 0x100650834 in apply_lambda eval.c:3088
    #94 0x100641c68 in eval_sub eval.c:2572
    #95 0x1006f5394 in readevalloop_eager_expand_eval lread.c:2160
    #96 0x1006e0b0c in readevalloop lread.c:2343
    #97 0x1006e236c in Feval_buffer lread.c:2416
    #98 0x100653d24 in funcall_subr eval.c:3025
    #99 0x10072e004 in exec_byte_code bytecode.c:809
    #100 0x10065c16c in fetch_and_exec_byte_code eval.c:3066
    #101 0x100654994 in funcall_lambda eval.c:3138
    #102 0x10065316c in funcall_general eval.c:2929
    #103 0x100647fcc in Ffuncall eval.c:2979
    #104 0x1006ddfe8 in call4 lisp.h:3317
    #105 0x1006d9058 in Fload lread.c:1483
    #106 0x100653d24 in funcall_subr eval.c:3025
    #107 0x10072e004 in exec_byte_code bytecode.c:809
    #108 0x10065c16c in fetch_and_exec_byte_code eval.c:3066
    #109 0x100654994 in funcall_lambda eval.c:3138
    #110 0x100650834 in apply_lambda eval.c:3088
    #111 0x100641734 in eval_sub eval.c:2529
    #112 0x10064efb0 in Feval eval.c:2345
    #113 0x100451650 in top_level_2 keyboard.c:1141
    #114 0x10064a318 in internal_condition_case eval.c:1471
    #115 0x100451564 in top_level_1 keyboard.c:1149
    #116 0x100648aa4 in internal_catch eval.c:1194
    #117 0x100416f04 in command_loop keyboard.c:1109
    #118 0x100416994 in recursive_edit_1 keyboard.c:719
    #119 0x100417950 in Frecursive_edit keyboard.c:802
    #120 0x10040fb00 in main emacs.c:2515
    #121 0x101549088 in start+0x204 (dyld:arm64e+0x5088)

That is redisplay during garbage_collect!

The change to probably_quit didn't help.  Commenting out the call to
redisplay in the layout stuff did.
This bug report was last modified 2 years and 74 days ago.

Previous Next

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