From nobody Thu Apr 2 22:21:30 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 E6F593502AB for ; Fri, 13 Feb 2026 15:48:43 +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=1770997724; cv=none; b=dQx4TuJV2fPZEu16RC3AaSZOrJ3n5Yy9UR+r/n63/Tg0ZsgUoaDPf/fwG+DEp+yXcIkfOtjIHfklnZSk4nsI03Z18XbropkduInv6WerYA9PXjQvZgx1aPzOXbYJuuQlYnrRCMx97sS0zSCwEVdwHcYZ59DKbRFftOjLuZ4B8oE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770997724; c=relaxed/simple; bh=PTJFDGkeSN26ugvAI4aRe+dHGTbs5yOXGvLemsc0sMk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TwThBGNHKp9huHwX27jKs4JvcTIeYqj3orvjUz5MVhLcP89pXhm/0tN7cgBgjuJMCr/ouv4Y/M25YqnmevhQN/IIMXO+qL2098fdMOb0lLVV4/iVx3KEWEHfUpluC9MT7aIS7ENBHGvc3Z9liMO9ecVyjq3epvI89kd5Cp0k+OM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=A5i2uuQp; 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="A5i2uuQp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58029C16AAE; Fri, 13 Feb 2026 15:48:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770997723; bh=PTJFDGkeSN26ugvAI4aRe+dHGTbs5yOXGvLemsc0sMk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=A5i2uuQpF4s1RFOexFyOdlWT+dXE1qKCpXkjUA0xr/6UY1MoU+yVgL9QvHoHDM8IH rC431ghZqIHGKIL6pVXQ+0+4eQmd2glx1lLIlywGoD2re53AX+ch0/uyhKc2EIq8cf 6SNYfTseYYlyvuflEn8V/8GJSV21MAskpD0706/8XWrDujqh6ISUuxFNC4HB+vPxmL eIxtXbi10RQLYhZBOS7c7uR4tW+2NPD5wU36IkEkyVpVUNJ51GTeqUeMrwnJePnZId d2zLfhxtUd6qY4o9kcgFL3UQEbttabvpBsumzZxNnE0vESnBZEuZdKh0g+gs21p00f HPFAulJJy8OvA== Received: from phl-compute-08.internal (phl-compute-08.internal [10.202.2.48]) by mailfauth.phl.internal (Postfix) with ESMTP id 84B87F40069; Fri, 13 Feb 2026 10:48:42 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-08.internal (MEProxy); Fri, 13 Feb 2026 10:48:42 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvtdekieehucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepfdfmihhrhihl ucfuhhhuthhsvghmrghuucdlofgvthgrmddfuceokhgrsheskhgvrhhnvghlrdhorhhgqe enucggtffrrghtthgvrhhnpefhudejfedvgeekffefvdekheekkeeuveeftdelheegteel gfefveevueekhfdtteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehkihhrihhllhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidq udeiudduiedvieehhedqvdekgeeggeejvdekqdhkrghspeepkhgvrhhnvghlrdhorhhgse hshhhuthgvmhhovhdrnhgrmhgvpdhnsggprhgtphhtthhopeduvddpmhhouggvpehsmhht phhouhhtpdhrtghpthhtoheprghruggssehkvghrnhgvlhdrohhrghdprhgtphhtthhope htghhlgieskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepmhhinhhgohesrhgvughhrght rdgtohhmpdhrtghpthhtohepsghpsegrlhhivghnkedruggvpdhrtghpthhtohepuggrvh gvrdhhrghnshgvnheslhhinhhugidrihhnthgvlhdrtghomhdprhgtphhtthhopehthhho mhgrshdrlhgvnhgurggtkhihsegrmhgurdgtohhmpdhrtghpthhtohepgiekieeskhgvrh hnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgv lhdrohhrghdprhgtphhtthhopehlihhnuhigqdhmmheskhhvrggtkhdrohhrgh X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 13 Feb 2026 10:48:42 -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 , "Kiryl Shutsemau (Meta)" Subject: [PATCH 1/2] efi: Fix reservation of unaccepted memory table Date: Fri, 13 Feb 2026 15:48:37 +0000 Message-ID: <20260213154838.46567-2-kas@kernel.org> X-Mailer: git-send-email 2.51.2 In-Reply-To: <20260213154838.46567-1-kas@kernel.org> References: <20260213154838.46567-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) --- 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:21:30 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 5C9E123183B for ; Fri, 13 Feb 2026 15:48:45 +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=1770997725; cv=none; b=gk6jw/TkRDm2Mv52KHoP20AR9cABC12Kc3YgFEKRat5GZXitOLXRdqxG75uMxi2AO8lXUbYld20Qn0NAxAOn8zJpoJpjU/6ZBHEntOVaNFULGjnNhHzf9u4SNyXBX9JxbArGx+f3kXR5KBUHFWR2emwpbAF7HkOL7ZyyBr4Miv8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770997725; c=relaxed/simple; bh=7dPdpuhsrQod7cEGqKBOY+A3ayeNPxUOOxb86J+eqNA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RcK6eDLYIYyY282SAQ+hRiSTUOG917/iVtQzZky7foLlm3yq7ByBKnzmPw2OlzWuDmBXrLNZyn+4MqSGPj+lK6fxBdKmA6SHyRaBVAWYPHIxZ8QCN0/GxgeqGkZv4KUW/DEFqeVnZCwS1r1XVU2mTgFJqI2Wlw7ulR8l0av3gYM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WHbMe4ts; 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="WHbMe4ts" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D4B29C19424 for ; Fri, 13 Feb 2026 15:48:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770997725; bh=7dPdpuhsrQod7cEGqKBOY+A3ayeNPxUOOxb86J+eqNA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WHbMe4tsgtS4AB8kNPkasw4v4lIQx2jJiY4rmeA074j6L8cF3+MZQ4D51RAcKGB43 4YTjW61e3GFaBQOzYm2xXqtQtpaurWHtziQp8VyBgYcMVGPABU7oY2rzUqLCu5ER07 Wa4ClhCwTpRiKNhrBmIOljHVeeCDPYCVvS/A9R+afBGRyhi1v/uyBmk2U82Nc9o9Fs qrQvn3KlaU3mV+SLsBL0JkV56mdYzxgg6U8rILsBe+kUuZUESqy3yEuO1K1DvvqsXD xlo9CpXhJsSOMjPpoHROtxuMG06ANGKtIOFhqK2yD9B2cQ06Ss3tgvIjk665+gZ3Rj QP1w4MCwP+xFQ== Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfauth.phl.internal (Postfix) with ESMTP id 0C048F40069; Fri, 13 Feb 2026 10:48:44 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Fri, 13 Feb 2026 10:48:44 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvtdekieehucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepfdfmihhrhihl ucfuhhhuthhsvghmrghuucdlofgvthgrmddfuceokhgrsheskhgvrhhnvghlrdhorhhgqe enucggtffrrghtthgvrhhnpefhudejfedvgeekffefvdekheekkeeuveeftdelheegteel gfefveevueekhfdtteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehkihhrihhllhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidq udeiudduiedvieehhedqvdekgeeggeejvdekqdhkrghspeepkhgvrhhnvghlrdhorhhgse hshhhuthgvmhhovhdrnhgrmhgvpdhnsggprhgtphhtthhopeduvddpmhhouggvpehsmhht phhouhhtpdhrtghpthhtoheprghruggssehkvghrnhgvlhdrohhrghdprhgtphhtthhope htghhlgieskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepmhhinhhgohesrhgvughhrght rdgtohhmpdhrtghpthhtohepsghpsegrlhhivghnkedruggvpdhrtghpthhtohepuggrvh gvrdhhrghnshgvnheslhhinhhugidrihhnthgvlhdrtghomhdprhgtphhtthhopehthhho mhgrshdrlhgvnhgurggtkhihsegrmhgurdgtohhmpdhrtghpthhtohepgiekieeskhgvrh hnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgv lhdrohhrghdprhgtphhtthhopehlihhnuhigqdhmmheskhhvrggtkhdrohhrgh X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 13 Feb 2026 10:48:43 -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 , "Kiryl Shutsemau (Meta)" Subject: [PATCH 2/2] efi: Align unaccepted memory range to page boundary Date: Fri, 13 Feb 2026 15:48:38 +0000 Message-ID: <20260213154838.46567-3-kas@kernel.org> X-Mailer: git-send-email 2.51.2 In-Reply-To: <20260213154838.46567-1-kas@kernel.org> References: <20260213154838.46567-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) --- drivers/firmware/efi/unaccepted_memory.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/firmware/efi/unaccepted_memory.c b/drivers/firmware/ef= i/unaccepted_memory.c index c2c067eff634..9ddf3dedd514 100644 --- a/drivers/firmware/efi/unaccepted_memory.c +++ b/drivers/firmware/efi/unaccepted_memory.c @@ -35,14 +35,18 @@ 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 + start =3D PAGE_ALIGN_DOWN(start); + size =3D PAGE_ALIGN(size); + end =3D start + size; + unit_size =3D unaccepted->unit_size; =20 /* @@ -160,15 +164,19 @@ 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 + start =3D PAGE_ALIGN_DOWN(start); + size =3D PAGE_ALIGN(size); + end =3D start + size; + unit_size =3D unaccepted->unit_size; =20 /* --=20 2.51.2