From nobody Thu Apr 2 22:22:21 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2AC1B329C5F for ; Tue, 17 Feb 2026 10:50:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771325417; cv=none; b=aODGnqVSUyONMAQO0w7O1GRW6RjUVmlpgCynMbZPOhJPKBGZYAaJC25yvmEtmxipGLueGPeq3061nOKB6RUWpFE0CHiZJV+wv1Z9/Jho3M0QQw2nmIlm8G1f3Ynp9DZGPVNqy9GeUUsJ+/8KcBiCV4YAK0zIqQM9Faq7BWMEEhk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771325417; c=relaxed/simple; bh=PTJFDGkeSN26ugvAI4aRe+dHGTbs5yOXGvLemsc0sMk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GqztcZ3UsPlTXNthAYcBCOJMbOj5BwGWnc7IitF6mYdJFBA/P+q+uLATOfGEimZhFQFNAEO1Oy6JnV9R9B3T3BRnS55Y6z7uXjp4q87E5q1/pKiJff861UfPBtw3ZlfU0/JGDuCKlQ9EzSDpSiizzrEJ/KlC0Y8Gts4nUKBEM5U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IfKh9WZ7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IfKh9WZ7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 80280C19424; Tue, 17 Feb 2026 10:50:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771325416; bh=PTJFDGkeSN26ugvAI4aRe+dHGTbs5yOXGvLemsc0sMk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IfKh9WZ7rrdPHsMVJ8riwZwM6xKqp0tAAW1QxfpxaBVHwRnrQ8j6K0VMrZHUj28zm NFW6ntHDBQ224IVEeKCS5Mz1szVhs8TuOD+2gbf1W3HnI+pHzEwlQiQwFmYCmPIHwa +5d1CPmMbwc92MsdlaGwB5rUWNWBY4kQrQEwz4827MilsauUufQuD9ADJ3QKPp6wIf DBGlEyVr557YXLyQMljywb30TtNFh8gLPF7B00FL4x4ZB1FMA1k5xnFRGtCprJ5Pgl qQJ6P1Inp7tscdSnIEbSlA2cpukkyoH1Sqm3j4sOuS2MeRWPLawGY/Bh89GgQ3ONK1 KaMeOW4bnUlVg== Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfauth.phl.internal (Postfix) with ESMTP id 95F71F4006A; Tue, 17 Feb 2026 05:50:15 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-03.internal (MEProxy); Tue, 17 Feb 2026 05:50:15 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvudelheeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepfdfmihhrhihl ucfuhhhuthhsvghmrghuucdlofgvthgrmddfuceokhgrsheskhgvrhhnvghlrdhorhhgqe enucggtffrrghtthgvrhhnpefhudejfedvgeekffefvdekheekkeeuveeftdelheegteel gfefveevueekhfdtteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehkihhrihhllhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidq udeiudduiedvieehhedqvdekgeeggeejvdekqdhkrghspeepkhgvrhhnvghlrdhorhhgse hshhhuthgvmhhovhdrnhgrmhgvpdhnsggprhgtphhtthhopedufedpmhhouggvpehsmhht phhouhhtpdhrtghpthhtoheprghruggssehkvghrnhgvlhdrohhrghdprhgtphhtthhope htghhlgieskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepmhhinhhgohesrhgvughhrght rdgtohhmpdhrtghpthhtohepsghpsegrlhhivghnkedruggvpdhrtghpthhtohepuggrvh gvrdhhrghnshgvnheslhhinhhugidrihhnthgvlhdrtghomhdprhgtphhtthhopehthhho mhgrshdrlhgvnhgurggtkhihsegrmhgurdgtohhmpdhrtghpthhtohepgiekieeskhgvrh hnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgv lhdrohhrghdprhgtphhtthhopehlihhnuhigqdhmmheskhhvrggtkhdrohhrgh X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 17 Feb 2026 05:50:15 -0500 (EST) From: "Kiryl Shutsemau (Meta)" To: Ard Biesheuvel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Tom Lendacky Cc: x86@kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Moritz Sanft , Mike Rapoport , "Kiryl Shutsemau (Meta)" Subject: [PATCHv2 1/2] efi: Fix reservation of unaccepted memory table Date: Tue, 17 Feb 2026 10:49:56 +0000 Message-ID: <20260217104957.249340-2-kas@kernel.org> X-Mailer: git-send-email 2.51.2 In-Reply-To: <20260217104957.249340-1-kas@kernel.org> References: <20260217104957.249340-1-kas@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The reserve_unaccepted() function incorrectly calculates the size of the memblock reservation for the unaccepted memory table. It aligns the size of the table, but fails to account for cases where the table's starting physical address (efi.unaccepted) is not page-aligned. If the table starts at an offset within a page and its end crosses into a subsequent page that the aligned size does not cover, the end of the table will not be reserved. This can lead to the table being overwritten or inaccessible, causing a kernel panic in accept_memory(). This issue was observed when starting Intel TDX VMs with specific memory sizes (e.g., > 64GB). Fix this by calculating the end address first (including the unaligned start) and then aligning it up, ensuring the entire range is covered by the reservation. Fixes: 8dbe33956d96 ("efi/unaccepted: Make sure unaccepted table is mapped") Reported-by: Moritz Sanft Signed-off-by: Kiryl Shutsemau (Meta) Acked-by: Mike Rapoport (Microsoft) Reviewed-by: Tom Lendacky --- drivers/firmware/efi/efi.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c index 111e87a618e5..56e9d73412fa 100644 --- a/drivers/firmware/efi/efi.c +++ b/drivers/firmware/efi/efi.c @@ -692,13 +692,13 @@ static __init int match_config_table(const efi_guid_t= *guid, =20 static __init void reserve_unaccepted(struct efi_unaccepted_memory *unacce= pted) { - phys_addr_t start, size; + phys_addr_t start, end; =20 start =3D PAGE_ALIGN_DOWN(efi.unaccepted); - size =3D PAGE_ALIGN(sizeof(*unaccepted) + unaccepted->size); + end =3D PAGE_ALIGN(efi.unaccepted + sizeof(*unaccepted) + unaccepted->siz= e); =20 - memblock_add(start, size); - memblock_reserve(start, size); + memblock_add(start, end - start); + memblock_reserve(start, end - start); } =20 int __init efi_config_parse_tables(const efi_config_table_t *config_tables, --=20 2.51.2 From nobody Thu Apr 2 22:22:21 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 455FD329C78 for ; Tue, 17 Feb 2026 10:50:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771325419; cv=none; b=tZ+KfK6VehACNAd21E59OX0q3Uo9GY5WZi3mpwrJXv7hFNnSGfIs7Q42xP+jMDRpAAWjr7xe3LmLyulecLd5Ra3cD1T4OgIWKiyK7xSNKO/HKKRpmK+pjqi9fa3CmNAEsuULgRSmRts9kprSsDTINVYhm8qVLFGz8x+O6QTfjuA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771325419; c=relaxed/simple; bh=xE/869Bo+esNtn+UnIQSf4BQa1m8IjcPxSsG7/pPAWw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZP9zL5nZHFmaVJZqz2pEvE4okXj7tcZ8tx7QSYLPvbEp4NJ4iX2R5MLCS9UDMypR9aCqXV/bBOgsFjzejhsj3h7jruwnMCLPCroU0shek7/PwA5miNU+BgYYBn+Awb3m14bconQwoY5OZ0WGBMUhwgWVSeL9iO4blA/+4tgIZ6M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tbjV/W9X; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tbjV/W9X" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8DFA3C4AF0B; Tue, 17 Feb 2026 10:50:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771325419; bh=xE/869Bo+esNtn+UnIQSf4BQa1m8IjcPxSsG7/pPAWw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tbjV/W9XJxSiC75k/8A1lJn0OwBb771o6lywyOsF4sHJULJ7gQiIst6onqtmWMQb2 IaCAKopQ9Ktyk7vz/hTqSfkUtMx6FAgU4gab8z1BTX0Adjx3tzuDzruFvjSQu/uXJ+ Tkhde+mprxQ4SebqbMxy1m3oQYYApOkHBlUbcOwQUiPfRY3R/vBE/JAHaHB5A26UmA BNbRyGoOe1gFEOFVTytNJ5tyWg4k6iffxMThca7oaTzZ7hqbWnbRfTtM/TMsw8WyJl zRi39IaleaRISYNnSIG0ALgj22Y3TV+o4ITYlcmeohNeq5uKmElOmwK/EaHeDKG5zH KnqdKCOfAa1tQ== Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailfauth.phl.internal (Postfix) with ESMTP id B7660F4006B; Tue, 17 Feb 2026 05:50:17 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-12.internal (MEProxy); Tue, 17 Feb 2026 05:50:17 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvudelheeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepfdfmihhrhihl ucfuhhhuthhsvghmrghuucdlofgvthgrmddfuceokhgrsheskhgvrhhnvghlrdhorhhgqe enucggtffrrghtthgvrhhnpefhudejfedvgeekffefvdekheekkeeuveeftdelheegteel gfefveevueekhfdtteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehkihhrihhllhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidq udeiudduiedvieehhedqvdekgeeggeejvdekqdhkrghspeepkhgvrhhnvghlrdhorhhgse hshhhuthgvmhhovhdrnhgrmhgvpdhnsggprhgtphhtthhopedufedpmhhouggvpehsmhht phhouhhtpdhrtghpthhtoheprghruggssehkvghrnhgvlhdrohhrghdprhgtphhtthhope htghhlgieskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepmhhinhhgohesrhgvughhrght rdgtohhmpdhrtghpthhtohepsghpsegrlhhivghnkedruggvpdhrtghpthhtohepuggrvh gvrdhhrghnshgvnheslhhinhhugidrihhnthgvlhdrtghomhdprhgtphhtthhopehthhho mhgrshdrlhgvnhgurggtkhihsegrmhgurdgtohhmpdhrtghpthhtohepgiekieeskhgvrh hnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgv lhdrohhrghdprhgtphhtthhopehlihhnuhigqdhmmheskhhvrggtkhdrohhrgh X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 17 Feb 2026 05:50:17 -0500 (EST) From: "Kiryl Shutsemau (Meta)" To: Ard Biesheuvel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Tom Lendacky Cc: x86@kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Moritz Sanft , Mike Rapoport , "Kiryl Shutsemau (Meta)" Subject: [PATCHv2 2/2] efi: Align unaccepted memory range to page boundary Date: Tue, 17 Feb 2026 10:49:57 +0000 Message-ID: <20260217104957.249340-3-kas@kernel.org> X-Mailer: git-send-email 2.51.2 In-Reply-To: <20260217104957.249340-1-kas@kernel.org> References: <20260217104957.249340-1-kas@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The accept_memory() and range_contains_unaccepted_memory() functions employ a "guard page" logic to prevent crashes with load_unaligned_zeropad(= ). This logic extends the range to be accepted (or checked) by one unit_size if the end of the range is aligned to a unit_size boundary. However, if the caller passes a range that is not page-aligned, the 'end' of the range might not be numerically aligned to unit_size, even if it covers the last page of a unit. This causes the "if (!(end % unit_siz= e))" check to fail, skipping the necessary extension and leaving the next unit unaccepted, which can lead to a kernel panic when accessed by load_unaligned_zeropad(). Align the start address down and the size up to the nearest page boundary before performing the unit_size alignment check. This ensures that the guard unit is correctly added when the range effectively ends on a unit boundary. Signed-off-by: Kiryl Shutsemau (Meta) Acked-by: Mike Rapoport (Microsoft) Reviewed-by: Tom Lendacky --- drivers/firmware/efi/unaccepted_memory.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/firmware/efi/unaccepted_memory.c b/drivers/firmware/ef= i/unaccepted_memory.c index c2c067eff634..4a8ec8d6a571 100644 --- a/drivers/firmware/efi/unaccepted_memory.c +++ b/drivers/firmware/efi/unaccepted_memory.c @@ -35,14 +35,17 @@ void accept_memory(phys_addr_t start, unsigned long siz= e) struct efi_unaccepted_memory *unaccepted; unsigned long range_start, range_end; struct accept_range range, *entry; - phys_addr_t end =3D start + size; unsigned long flags; + phys_addr_t end; u64 unit_size; =20 unaccepted =3D efi_get_unaccepted_table(); if (!unaccepted) return; =20 + end =3D PAGE_ALIGN(start + size); + start =3D PAGE_ALIGN_DOWN(start); + unit_size =3D unaccepted->unit_size; =20 /* @@ -160,15 +163,18 @@ void accept_memory(phys_addr_t start, unsigned long s= ize) bool range_contains_unaccepted_memory(phys_addr_t start, unsigned long siz= e) { struct efi_unaccepted_memory *unaccepted; - phys_addr_t end =3D start + size; unsigned long flags; bool ret =3D false; + phys_addr_t end; u64 unit_size; =20 unaccepted =3D efi_get_unaccepted_table(); if (!unaccepted) return false; =20 + end =3D PAGE_ALIGN(start + size); + start =3D PAGE_ALIGN_DOWN(start); + unit_size =3D unaccepted->unit_size; =20 /* --=20 2.51.2