CVE-2026-90341

What it actually does

Malformed coreboot firmware tables bypass bounds validation in coreboot_table_probe and coreboot_table_populate, allowing the kernel to map and parse memory outside the supplied resource; this produces out-of-bounds reads that can leak kernel memory or trigger crashes.

Why it matters to the business

Linux systems that rely on coreboot firmware may experience unexpected crashes or exposure of sensitive kernel data during boot; the issue affects a wide range of embedded, server, and desktop deployments that use the coreboot table interface.

How an attack unfolds

An attacker with the ability to influence or replace the coreboot table presented to the kernel at boot supplies a header claiming an extent larger than the actual resource or a size that overflows 32-bit addition. The driver maps the advertised region without further checks, then parses entries that read or dereference memory beyond the intended bounds, enabling local information disclosure or denial of service.

How to fix it

Update to a kernel containing the upstream fix that rejects resources shorter than the fixed header, validates the advertised extent with overflow checking, and refuses extents beyond the resource before remapping. Rebuild and redeploy any custom kernels or distributions that incorporate the coreboot driver.

How to confirm the fix worked

Confirm the patch is present by inspecting the coreboot_table_probe function for the added length, signature, and overflow checks; test by supplying a deliberately malformed table in a controlled environment and verifying the driver now rejects it instead of mapping outside the resource.

Typical attack path

1. Gain local or physical access sufficient to modify the coreboot table presented to the kernel
2. Craft a table whose header advertises an extent beyond the resource or triggers 32-bit size overflow
3. Cause the system to boot or reload the coreboot driver so coreboot_table_probe executes the faulty mapping
4. Trigger entry parsing that performs out-of-bounds reads to disclose kernel memory or induce a crash

How to detect it

Review kernel boot logs and dmesg output for coreboot table mapping messages that indicate unexpected sizes or failed probes; examine crash dumps or oops reports that reference coreboot_table functions for signs of out-of-bounds access.

What your security team should do

• Prioritize kernel updates on all coreboot-based systems within standard change windows
• Include the coreboot driver in regression test suites that exercise firmware table parsing
• Monitor upstream stable and distribution kernel releases for the backported bounds checks