From nobody Thu Oct 30 18:35:15 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org ARC-Seal: i=1; a=rsa-sha256; t=1753532823; cv=none; d=zohomail.com; s=zohoarc; b=VEIiqVcTcIycC00acz8reHBi2/ZDEoPUh8u9fzpi5xakBHEZc0H6U6Tyb0L9L0RFUm3uMiaTxXBXf5pQKyLGzJiP1flK9tU7T1M/gpHHKmpo9RR1vT64CfgfmevCiQoHVNpX2TFA3WzkpTFeKDvddgLhr4gNxnS3cggEasn+tpM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1753532823; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=QW/0in0rumyjgLuN3TDJ8pQ2bHfalq3y0x45zgyP5OM=; b=gq6q0Et6IHPg82zWVZPzqYGhKwdB4Z280f+uF6JK5tOSSQEGoiE5I6akB1eCYe+tslEWR2lYcHOHtwSy7HimUKIKa/1damJvP2PiNPFjvLMQgVbNVQ08BFZQssHjFxqieAQwRVf7wBYKUkiqrfbuKw9g+Vk7mcQOFR3+GP0DGCU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1753532823520191.20610688208376; Sat, 26 Jul 2025 05:27:03 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1059280.1426376 (Exim 4.92) (envelope-from ) id 1ufdz2-0005L4-2O; Sat, 26 Jul 2025 12:26:36 +0000 Received: by outflank-mailman (output) from mailman id 1059280.1426376; Sat, 26 Jul 2025 12:26:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ufdz1-0005Kx-W5; Sat, 26 Jul 2025 12:26:35 +0000 Received: by outflank-mailman (input) for mailman id 1059280; Sat, 26 Jul 2025 12:26:34 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ufdz0-0005Kr-Nw for xen-devel@lists.xenproject.org; Sat, 26 Jul 2025 12:26:34 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1ufdz0-002IjE-0i; Sat, 26 Jul 2025 12:26:34 +0000 Received: from 54-240-197-232.amazon.com ([54.240.197.232] helo=dev-dsk-jgrall-1b-035652ec.eu-west-1.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1ufdyz-00CgtV-2h; Sat, 26 Jul 2025 12:26:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:Message-ID:Date: Subject:Cc:To:From; bh=QW/0in0rumyjgLuN3TDJ8pQ2bHfalq3y0x45zgyP5OM=; b=EPkLJd /q73HoXAtmKrJlmyd6ZOOoDGH6WFXMF7bnID4Yj4flfBLxB3Ildmawyi2z2FwGguNLVKqhaw9qYtr ZX7td/Uey5pDkwRKgSa3p81Y5wld0Kk9zhzdhPWuXDPozn7MbcwfPo+keI+bB6OlbHxaaN/htU883 uJ3zYYOWDi0=; From: Julien Grall To: xen-devel@lists.xenproject.org Cc: julien@xen.org, Julien Grall , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Oleksii Kurochko Subject: [PATCH] P2M: Don't try to free the existing PTE if we can't allocate a new table Date: Sat, 26 Jul 2025 13:26:07 +0100 Message-ID: <20250726122607.75950-1-julien@xen.org> X-Mailer: git-send-email 2.47.3 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @xen.org) X-ZM-MESSAGEID: 1753532824616116600 Content-Type: text/plain; charset="utf-8" From: Julien Grall When we can't split a superpage (on Arm p2m_split_superpage() returns false, on x86 ept_split_superpage() returns 0), the caller is expected to clean any PTE that may have been allocated. However, when we can't allocate the page-tables 'entry' (arm) / 'ept_entry' still points to a live PTE. So we will end up to free a PTE that is still used. In practice for: * x86: We don't do any refcounting for 2MB/1GB mappings. So this is harmless * arm: We do refcounting for 2MB mapping (not for 1GB ones). This is only used for static memory. So there is a security issue on Arm but this doesn't meet the criteria for an XSA (static memory is not security supported). Solve the issue by clearing the PTE if we can't allocate the table. Reported-by: Oleksii Kurochko Signed-off-by: Julien Grall ---- I decided to not split the patch in two as the issue for x86 and arm is the same. But I am happy to split if this is preferred. --- xen/arch/arm/mmu/p2m.c | 8 ++++++++ xen/arch/x86/mm/p2m-ept.c | 9 +++++++++ 2 files changed, 17 insertions(+) diff --git a/xen/arch/arm/mmu/p2m.c b/xen/arch/arm/mmu/p2m.c index 51abf3504fcf..9a1fb44a0204 100644 --- a/xen/arch/arm/mmu/p2m.c +++ b/xen/arch/arm/mmu/p2m.c @@ -888,7 +888,15 @@ static bool p2m_split_superpage(struct p2m_domain *p2m= , lpae_t *entry, =20 page =3D p2m_alloc_page(p2m->domain); if ( !page ) + { + /* + * The caller is in charge to free the sub-tree. So tell the + * As we didn't manage to allocate anything, just tell the + * caller there is nothing to free by invalidating the PTE. + */ + memset(entry, 0, sizeof(*entry)); return false; + } =20 page_list_add(page, &p2m->pages); table =3D __map_domain_page(page); diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c index 62fc8e50689f..1efac27835d2 100644 --- a/xen/arch/x86/mm/p2m-ept.c +++ b/xen/arch/x86/mm/p2m-ept.c @@ -261,7 +261,16 @@ static bool ept_split_super_page( =20 table =3D ept_set_middle_entry(p2m, &new_ept); if ( !table ) + { + /* + * The caller is in charge to free the sub-tree. So tell the + * As we didn't manage to allocate anything, just tell the + * caller there is nothing to free by invalidating the PTE. + */ + memset(ept_entry, 0, sizeof(*ept_entry)); + return 0; + } =20 trunk =3D 1UL << ((level - 1) * EPT_TABLE_ORDER); =20 --=20 2.47.3