From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Newsgroups: gmane.emacs.bugs Subject: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal Date: Sun, 25 Sep 2022 07:50:17 +0200 Message-ID: References: <835yhcom6g.fsf@gnu.org> <831qs0okx4.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5002"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) Cc: 58042@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Sep 25 07:51:31 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ocKY5-00016s-Qd for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 25 Sep 2022 07:51:29 +0200 Original-Received: from localhost ([::1]:46494 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ocKY4-0005M9-2q for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 25 Sep 2022 01:51:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41664) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocKXe-0005M1-FT for bug-gnu-emacs@gnu.org; Sun, 25 Sep 2022 01:51:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46610) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ocKXe-0001AY-5J for bug-gnu-emacs@gnu.org; Sun, 25 Sep 2022 01:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ocKXd-0007u0-SF for bug-gnu-emacs@gnu.org; Sun, 25 Sep 2022 01:51:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Sep 2022 05:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58042 X-GNU-PR-Package: emacs Original-Received: via spool by 58042-submit@debbugs.gnu.org id=B58042.166408503329560 (code B ref 58042); Sun, 25 Sep 2022 05:51:01 +0000 Original-Received: (at 58042) by debbugs.gnu.org; 25 Sep 2022 05:50:33 +0000 Original-Received: from localhost ([127.0.0.1]:45688 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ocKX9-0007gg-5x for submit@debbugs.gnu.org; Sun, 25 Sep 2022 01:50:33 -0400 Original-Received: from mail-ed1-f51.google.com ([209.85.208.51]:33349) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ocKX4-0007g3-5y for 58042@debbugs.gnu.org; Sun, 25 Sep 2022 01:50:30 -0400 Original-Received: by mail-ed1-f51.google.com with SMTP id b35so5162645edf.0 for <58042@debbugs.gnu.org>; Sat, 24 Sep 2022 22:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date; bh=/Ni02pfISPhDeHCuP12keLMrbC8Qw3wyTH4LRrF5e6s=; b=PysotDSVrqyZ5bIbSF966XYktkqI+gHNpE/uAAQcSyumD/BnNcpnj2I7fHPkkKLssF IoTG860sTaxryq3jdOYPSsrjfn76Fw6qDKHttiYbHDzOfWecTzPSXnecNzZBF1gVrlFh rfDJo/c5xjJr+I+lta6EGztETI8B1nwzOwS55444Gb0rQxjWgm5KaZGm2lu+2RIVky77 8lJtR/uRCIWXNcYbvxhllEyfV/SEypFoiNykD+i/DOl48yAJEIhrMitD6CrB5iE5q6U2 SjZwis9zzXVijFZQ8eM8+yP6iDkxJpSjr0djIB7jbS3ezevwy1208eiXjD/sjldsfGzR BgAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date; bh=/Ni02pfISPhDeHCuP12keLMrbC8Qw3wyTH4LRrF5e6s=; b=1nrHKl1nG47zrLNKMGa4x8Sx/3MM3/oDHFL1t8AO4n6p8D/TbReXt8xX4TLjxyBXDS wmCankCismof6nEHF/fGZH/trO2jj3HSGjU5JGq1zRXDlMUOPnYjphn79mtDUPBL3peE 0bJfnd6DzK621BuG+7YpqAmRwopkYH9c+jco9+w10ZJWgu2MOUYwxbRdAPtxSwsp5VW6 cYnn/kHxIDMEEYH+EziCBymLQElg8rvqgpeyPbo04bgo7gqHB3BfRqP2VdXW1SCdjbwe X/n7sRoqIZLSS/qugzgVTOoH+KkUOgGVH5zOb12dT2lJzdEQnHbt6EhC//L5nd7wv4MQ PlNg== X-Gm-Message-State: ACrzQf25gW2EYfQxkLmnBMaBWXy4IpCrZ3ssXFqdtSbuNHSCXyouOX87 HeRWXPtGcCYHfdl4tEJizdZh3mRJ64o= X-Google-Smtp-Source: AMsMyM45KmPP+DUmkNhZleiauj6IYHObuewQIsrbXW5YeckHngglT0hYJf1PDIdXP9Ei4J7sfP26jQ== X-Received: by 2002:a05:6402:1d86:b0:457:e84:f0e with SMTP id dk6-20020a0564021d8600b004570e840f0emr4453562edb.241.1664085019692; Sat, 24 Sep 2022 22:50:19 -0700 (PDT) Original-Received: from Mini.fritz.box (pd9e362ca.dip0.t-ipconnect.de. [217.227.98.202]) by smtp.gmail.com with ESMTPSA id b11-20020a170906194b00b0072ed9efc9dfsm6384898eje.48.2022.09.24.22.50.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 24 Sep 2022 22:50:18 -0700 (PDT) In-Reply-To: <831qs0okx4.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 24 Sep 2022 18:24:07 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:243566 Archived-At: Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: 58042@debbugs.gnu.org >> Date: Sat, 24 Sep 2022 17:08:12 +0200 >>=20 >> But in general, I think the small string compaction could be a serious >> problem here, as soon as a GC happens while the regexp machine holds >> pointers. > > What is the path from regexp match to GC? I think since bug#56108 it's safe to say that a GC can happen while matching. In that bug, a regexp_cache entry was "freed" by GC. > The GC was triggered by > redisplay, but how did redisplay start while regexp match was in > progress? Do you see any code in regexp that could trigger redisplay? I'm afraid, I don't follow. Why do you think redisplay comes into play here? Anyways, my working hypotheses currently goes like this: We match using some Lisp string S and get its data pointer, say D. Since D is not null, S must be a live string. (Actually I didn't check that this is still the case, but I think I've been setting s.data to null for free strings right from the start, and I can't imagine why anyone would change that.) Between the point we get D, and the point of the crash, a GC happens. We know in principle that a GC can happen while matching since bug#56108. I'm taking that as a given. The GC compacts strings and changes S's data pointer. After GC, S.data !=3D D. Now, ASAN knows that a struct sdata was allocated and freed in the past that contains S.data. Or perhaps better said S.data points into the part of the the freed struct sdata that ASAN checks. How can that hapoen? I have no idea, but that's the scenario I give the most credibility so far. WDYT?