From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.bugs Subject: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Date: Sun, 05 Jan 2025 18:28:59 -0500 Message-ID: <87sepwvo04.fsf@dancol.org> References: <87jzbbke6u.fsf@protonmail.com> <87msg7iq0o.fsf@protonmail.com> <86ed1jf1tp.fsf@gnu.org> <865xmugawr.fsf@gnu.org> <8634hx8k1u.fsf@gnu.org> <225431A0-98C1-4F95-B290-AB86F5379030@dancol.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="31514"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.12.8; emacs 31.0.50 Cc: gerd.moellmann@gmail.com, eliz@gnu.org, pipcet@protonmail.com To: 75322@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 06 00:30:29 2025 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 1tUa4i-00084J-MF for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 06 Jan 2025 00:30:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUa4K-00030M-Rj; Sun, 05 Jan 2025 18:30:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tUa4J-0002ye-OH for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 18:30:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tUa4J-0002U1-DL for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 18:30:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=CY6MM83M+8Y2t/E38eNXGJmZDratcczERmaWgPv7Vu0=; b=bjtj74lptk2JiuPupTwTcu24Qiped0EbljiUzVN0YrjkDSM6rov/2SZQPrtaTNRU/yZObWrV4b9qJdpnQS3edLtT489+YpsN/nxtcALDL28wwTXBP1DIw8nkKXA4K9ShMAaSsqCC80Qq2DXkqN/G8tAUnj+VJhU44nFs8dvqFZ+Dp2E8AqaA9VQqU6guUVDzi23hcUDj313p0kAM/S/WxbMdQKsibh5zCC1lIkWQvEJK60C2YKiIyZ6w5ZDh15kO7Mb6QqGcevzivJjtskD7/wrXeyY6CTFCVlOh+nUjgK63/lXW9CNOsspwMrxjwti6K8Husq6+4oRKiGI3cDh/Rg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tUa4J-0003YF-6h for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 18:30:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Jan 2025 23:30:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75322 X-GNU-PR-Package: emacs Original-Received: via spool by 75322-submit@debbugs.gnu.org id=B75322.173611974913548 (code B ref 75322); Sun, 05 Jan 2025 23:30:03 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 23:29:09 +0000 Original-Received: from localhost ([127.0.0.1]:35893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUa3Q-0003WR-Om for submit@debbugs.gnu.org; Sun, 05 Jan 2025 18:29:09 -0500 Original-Received: from dancol.org ([2600:3c01:e000:3d8::1]:44684) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tUa3N-0003WE-FD for 75322@debbugs.gnu.org; Sun, 05 Jan 2025 18:29:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=CY6MM83M+8Y2t/E38eNXGJmZDratcczERmaWgPv7Vu0=; b=LtiUPr6/2XXc80GS2hZKkGLFCG lGVMmWdkpG9iEcWt7c1fr1mjcNAs47AeRG4N1gQAJ2DLLVr4zfInmGTQKGzxhELpf+66+LCZ7M2rE Rk/JmOmJxEuALzN6ZjeIK5i3By9ma3+MN/g3owVFTIhPv0GaLVbuRA+iQVnv1IYo4grEQbS6mRzW/ pKfOU7ZKmMB4VShLCHqDr5UV7DBYQum/30/LRvBnNcFsbpWxC8vBXS8i5shvI16+/KLc49EkxKiha Q1IKiNQ2QrFJbSKQVPmqDxhqJPdAHOLPkhAdomd7R5mJqc0fN9hhhnMCQSB+Hh0iqBPIDFVlwNbaJ yBmQnPPw==; Original-Received: from 2603-9001-4203-1ab2-7ab6-aa97-d11e-5f4a.inf6.spectrum.com ([2603:9001:4203:1ab2:7ab6:aa97:d11e:5f4a]:54182 helo=localhost) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tUa3J-0006ej-2v; Sun, 05 Jan 2025 18:29:02 -0500 In-Reply-To: <225431A0-98C1-4F95-B290-AB86F5379030@dancol.org> (Daniel Colascione's message of "Sun, 05 Jan 2025 16:01:00 -0500") 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:298621 Archived-At: Daniel Colascione writes: > On January 5, 2025 9:11:08 AM EST, "Gerd M=C3=B6llmann" > wrote: >>Eli Zaretskii writes: >> >>>> From: Gerd M=C3=B6llmann >>>> Cc: pipcet@protonmail.com, 75322@debbugs.gnu.org >>>> Date: Sat, 04 Jan 2025 11:20:41 +0100 >>>>=20 >>>> In callproc.c I found two: call_process and create_temp_file both use >>>> SAFE_NALLOCA to store Lisp_Objects. I think these should be replaces >>>> with SAVE_ALLOCA_LISP. >>> >>> What are the conditions under which placing Lisp objects into >>> SAFE_NALLOCA is not safe? >>> >>> I understand that the first condition is that SAFE_NALLOCA uses >>> xmalloc instead of alloca. >> >>Right. If it doesn't use xmalloc, the references are on the C stack, and >>both old and new GC handle that by scanning the C stack. >> >>> But what are the other conditions? Is one of them that GC could >>> happen while these Lisp objects are in the memory allocated by >>> SAFE_NALLOCA off the heap?=20=20 >> >>Yes. >> >>> IOW, if no GC happen, is that still unsafe? And if GC _can_ happen, >>> but we don't use the allocated block again, is that a problem? For >>> example, in this fragment: >>> >>> SAFE_NALLOCA (args2, 1, nargs + 1); >>> args2[0] =3D Qcall_process; >>> for (i =3D 0; i < nargs; i++) args2[i + 1] =3D args[i]; >>> coding_systems =3D Ffind_operation_coding_system (nargs + 1, args2= ); >>> val =3D CONSP (coding_systems) ? XCDR (coding_systems) : Qnil; >>> >>> Let's say Ffind_operation_coding_system could trigger GC. But we >>> never again use the args2[] array after Ffind_operation_coding_system >>> returns. Is the above still unsafe? If so, could you tell what >>> could MPS do during GC to make this unsafe? >> >>Let me first say why I find this unsafe in the old GC, in principle. If >>we don't assume anything about the objects referenced from args2, then a >>reference in args2 may well be the only one to some object. In this >>case, the old GC would sweep it. > > Gerd is right. This pattern was never safe. Here's a demonstration of the problem. Run ./emacs -batch -Q --eval '(acos 0)'. If you leave demo_crash to true, Emacs will abort quickly after we detect a use-after-free. If you set demo_crash to false, Emacs will run the loop all day. diff --git a/src/floatfns.c b/src/floatfns.c index 065ae16e885..a95597beef8 100644 --- a/src/floatfns.c +++ b/src/floatfns.c @@ -50,6 +50,8 @@ Copyright (C) 1988, 1993-1994, 1999, 2001-2025 Free Softw= are Foundation, =20 #include =20 +#include + #include "lisp.h" #include "bignum.h" =20 @@ -86,6 +88,31 @@ DEFUN ("acos", Facos, Sacos, 1, 1, 0, doc: /* Return the inverse cosine of ARG. */) (Lisp_Object arg) { + Lisp_Object* args2; + unsigned start =3D 12345; + unsigned counter =3D start; + bool demo_crash =3D true; + + USE_SAFE_ALLOCA; + + SAFE_NALLOCA (args2, 1, 1 + (demo_crash ? MAX_ALLOCA : 0)); + args2[0] =3D Fcons (make_fixnum (counter), + make_fixnum (counter + 1)); + counter +=3D 2; + for (;;) + { + if (!FIXNUMP (XCAR (args2[0]))) + emacs_abort (); + if (XFIXNUM (XCAR (args2[0])) !=3D 12345) + emacs_abort (); + Fcons (make_fixnum (counter), + make_fixnum (counter + 1)); + Fgarbage_collect (); + fprintf (stderr, "."); + fflush (stderr); + counter +=3D 2; + } + double d =3D extract_float (arg); d =3D acos (d); return make_float (d);