CVE-2024-26843

What it actually does

Integer narrowing of md_size for soft-reserved EFI regions containing 4 GB or more pages can produce an incorrect (truncated) region size, resulting in memory corruption or out-of-bounds access during EFI runtime memory map handling.

Why it matters to the business

Linux systems may experience kernel crashes, memory corruption, or potential remote code execution, leading to unplanned downtime, data loss, or compromise of EFI-based servers and embedded devices; widespread kernel update required across distributions.

How an attack unfolds

An attacker with the ability to influence or observe EFI memory map construction (via crafted firmware tables or local code execution) triggers allocation or mapping of a soft-reserved region >=4 GB; the narrowed size value causes the kernel to miscalculate boundaries, enabling subsequent memory corruption primitives that can be chained into arbitrary read/write or code execution.

How to fix it

Upgrade the Linux kernel to the commit 4fff3d735baea104017f2e3c245e27cdc79f2426 or later stable releases that contain the fix; rebuild and reboot all affected systems; prioritize systems with large EFI memory regions.

How to confirm the fix worked

Confirm the running kernel contains commit 4fff3d735baea104017f2e3c245e27cdc79f2426 via 'uname -r' and kernel source; test EFI memory map initialization with large soft-reserved regions and verify no size truncation occurs in logs or debug output.

Typical attack path

1. Obtain local code execution or control over EFI memory map input
2. Trigger creation of a soft-reserved region with >=4 GB of pages
3. Force the kernel to compute md_size which is narrowed
4. Exploit resulting incorrect region size for out-of-bounds read/write
5. Escalate to kernel privileges or achieve persistence

How to detect it

Inspect kernel logs for EFI memory map warnings or size calculation anomalies during boot; correlate with unexpected crashes in efi or memory management subsystems; review audit logs for unusual EFI runtime service calls.

What your security team should do

• Immediately schedule kernel upgrades to the fixed commit across all Linux fleets
• Monitor vendor advisories for distribution backports of the fix
• Review EFI memory configurations on high-value systems for large soft-reserved regions
• Apply compensating controls such as disabling unnecessary EFI runtime services until patched