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

Previous Next

Full log

View this message in rfc822 format

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

Po Lu <luangruo <at> yahoo.com> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>>> 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.
>
> Today, event handling code calls Lisp all the time (through safe_call
> etc.)  That happens in handle_one_xevent, ns_select, et cetera.
>
> It shouldn't affect GC at all because input is blocked for the entire
> duration of each GC, except for when finalizers are run after unmarked
> objects are sweeped.
>
> So AFAIU it has been safe ever since read_socket_hook stopped being
> called from a signal handler.
>
>>> 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?
>
> It should be safe there since we use safe_call, as the only problem
> these days is that it isn't safe to longjmp out of an NS event handler.

Ok, I can't say much to this.  But please look at the my latest post.

Previous Next

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