From: Ard Biesheuvel <ardb+git@google.com>
To: linux-efi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
Ard Biesheuvel <ardb@kernel.org>, Dave Young <dyoung@redhat.com>,
Gregory Price <gourry@gourry.net>,
Usama Arif <usamaarif642@gmail.com>,
Jiri Slaby <jirislaby@kernel.org>,
Breno Leitao <leitao@debian.org>
Subject: [PATCH 1/5] efi/memattr: Fix thinko in table size sanity check
Date: Thu, 26 Mar 2026 14:26:57 +0100 [thread overview]
Message-ID: <20260326132655.1733873-8-ardb+git@google.com> (raw)
In-Reply-To: <20260326132655.1733873-7-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
While it is true that each PE/COFF runtime driver in memory can
generally be split into 3 different regions (the header, the code/rodata
region and the data/bss region), each with different permissions, it
does not mean that 3x the size of the memory map is a suitable upper
bound. This is due to the fact that all runtime drivers could be
coalesced into a single EFI runtime code region by the firmware, and if
the firmware does a good job of keeping the fragmentation down, it is
conceivable that the memory attributes table has more entries than the
EFI memory map itself.
So instead, base the sanity check on whether the descriptor size matches
the EFI memory map's descriptor size (which is not mandated by the spec
but extremely unlikely to differ in practice), and whether the size of
the whole table does not exceed 2 MiB.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
drivers/firmware/efi/memattr.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/efi/memattr.c b/drivers/firmware/efi/memattr.c
index e727cc5909cb..8d4004149297 100644
--- a/drivers/firmware/efi/memattr.c
+++ b/drivers/firmware/efi/memattr.c
@@ -42,14 +42,17 @@ void __init efi_memattr_init(void)
/*
- * Sanity check: the Memory Attributes Table contains up to 3 entries
- * for each entry of type EfiRuntimeServicesCode in the EFI memory map.
- * So if the size of the table exceeds 3x the size of the entire EFI
- * memory map, there is clearly something wrong, and the table should
- * just be ignored altogether.
+ * Sanity check: the Memory Attributes Table contains multiple entries
+ * for each EFI runtime services code or data region in the EFI memory
+ * map, each with the permission attributes that may be applied when
+ * mapping the region. There is no upper bound for the number of
+ * entries, as it could conceivably contain more entries than the EFI
+ * memory map itself. So pick an arbitrary limit of 2M for the size,
+ * which translates to ~50k entries of 40 bytes in size. This prevents
+ * a corrupted table from eating all system RAM.
*/
size = tbl->num_entries * tbl->desc_size;
- if (size > 3 * efi.memmap.nr_map * efi.memmap.desc_size) {
+ if (tbl->desc_size != efi.memmap.desc_size || size > SZ_2M) {
pr_warn(FW_BUG "Corrupted EFI Memory Attributes Table detected! (version == %u, desc_size == %u, num_entries == %u)\n",
tbl->version, tbl->desc_size, tbl->num_entries);
goto unmap;
--
2.53.0.1018.g2bb0e51243-goog
next prev parent reply other threads:[~2026-03-26 13:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-26 13:26 [PATCH 0/5] x86/efi: Re-enable memory attributes table for kexec Ard Biesheuvel
2026-03-26 13:26 ` Ard Biesheuvel [this message]
2026-03-29 17:51 ` [PATCH 1/5] efi/memattr: Fix thinko in table size sanity check Gregory Price
2026-03-26 13:26 ` [PATCH 2/5] x86/efi: Gather initial memory reservation and table handling logic Ard Biesheuvel
2026-03-29 17:53 ` Gregory Price
2026-03-26 13:26 ` [PATCH 3/5] x86/efi: Defer the call to efi_memattr_init() Ard Biesheuvel
2026-03-26 13:27 ` [PATCH 4/5] efi: Use efi_mem_reserve() to reserve the memory attribute table Ard Biesheuvel
2026-03-26 13:27 ` [PATCH 5/5] x86/efi: Drop kexec quirk for the EFI memory attributes table Ard Biesheuvel
2026-03-29 17:55 ` [PATCH 0/5] x86/efi: Re-enable memory attributes table for kexec Gregory Price
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260326132655.1733873-8-ardb+git@google.com \
--to=ardb+git@google.com \
--cc=ardb@kernel.org \
--cc=dyoung@redhat.com \
--cc=gourry@gourry.net \
--cc=jirislaby@kernel.org \
--cc=leitao@debian.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=usamaarif642@gmail.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox