CVE-2026-90341 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
firmware: coreboot: Validate table bounds
The existing coreboot_table_populate() bounds checks limit individual entries to the mapped length. However, coreboot_table_probe() replaces the platform resource length with header and table sizes supplied by firmware before mapping the full table.
A malformed table can overflow the 32-bit size addition or advertise an extent beyond the resource, causing the driver to map and parse memory outside the resource. A resource shorter than the fixed header is also mapped as though it contained a complete header.
Reject resources shorter than the fixed header. After validating the signature, require a complete header, calculate the advertised extent with overflow checking, and reject extents beyond the resource before remapping the table.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's coreboot firmware interface contains a critical logic flaw in how it validates and maps memory regions provided by the system firmware. The vulnerability stems from an inconsistency between two functions within the firmware subsystem: coreboot_table_populate() and coreboot_table_probe(). While populate correctly limits individual entries to the mapped length, probe performs a dangerous substitution of resource lengths with sizes supplied directly by the firmware before establishing the memory mapping. This architectural oversight allows malformed or maliciously crafted tables from the BIOS/UEFI to bypass standard boundary checks, leading to potential out-of-bounds reads and writes in kernel space.
The technical root cause involves improper validation of table extents during the initialization phase. When coreboot_table_probe() executes, it replaces the platform resource length with header and table sizes extracted directly from the firmware data structure before mapping the full table into kernel memory. If a malformed table advertises an extent that exceeds the actual physical resource limits, or if the size addition overflows its 32-bit integer representation, the driver proceeds to map and parse memory outside the designated resource boundaries. Furthermore, resources shorter than the fixed header required by coreboot are incorrectly mapped as though they contained a complete valid header, leading to undefined behavior when parsing subsequent fields that do not exist in physical memory.
This vulnerability poses significant operational risks including kernel panic, information disclosure, or potential privilege escalation depending on how an attacker can influence firmware contents during boot processes. By mapping and accessing memory outside the intended resource boundaries, an adversary with control over firmware data could read sensitive kernel memory structures or corrupt critical system state. The lack of overflow checking for size calculations exacerbates this risk, as integer wraparound could result in a small mapped region being used to access large areas of physical memory, effectively bypassing standard isolation mechanisms provided by the operating system's memory management unit.
To mitigate this vulnerability, strict validation procedures must be enforced before any memory mapping occurs. Resources shorter than the fixed header size required for coreboot tables should be immediately rejected without further processing. After validating the table signature to ensure it matches expected values, the implementation must require a complete and valid header structure. Crucially, the calculation of the advertised extent must include explicit overflow checking to prevent integer wraparound issues. Finally, before remapping or accessing any part of the table, the calculated extent must be verified against the actual resource length to ensure no access occurs beyond physical boundaries. This aligns with CWE-125 Out-of-bounds Read and CWE-190 Integer Overflow or Wraparound standards, while also addressing ATT&CK techniques related to firmware exploitation such as T1608 Link Exploitation for Persistence or Privilege Escalation via compromised boot components.