Cloudanix VulnDB

CVE-2026-23352

Medium · 5.5

CVSS

5.5

EPSS

0.1%

Published

Mar 25, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A startup memory-handling mistake in Linux can leave a large chunk of RAM unusable on computers that have very little memory to begin with, risking slowdowns or crashes.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Medium

What it actually does

The vulnerability stems from efi_free_boot_services() invoking memblock_free_late() on regions reserved via memblock_reserve() while CONFIG_DEFERRED_STRUCT_PAGE_INIT=y leaves portions of the memory map uninitialized; this causes memblock_free_pages() to skip the pages, resulting in a persistent ~140 MB RAM leak on low-memory systems.

Why it matters to the business

Resource-constrained Linux deployments may experience unexpected memory exhaustion shortly after boot, leading to degraded performance, service disruption, or crashes on systems with limited RAM; the low EPSS and absence from KEV indicate limited active exploitation risk at present.

How an attack unfolds

An attacker with local access boots a vulnerable kernel on an affected low-RAM x86 system with deferred struct page init enabled; the improper freeing sequence leaves EFI boot services memory allocated, exhausting available RAM without any further attacker action required.

How to fix it

Update to a Linux kernel containing the split efi_unmap_boot_services() / efi_free_boot_services() logic that defers freeing until after deferred page init completes; rebuild and reboot with the corrected kernel image.

How to confirm the fix worked

Boot the patched kernel on a test system matching the affected configuration, verify that memblock accounting shows the EFI boot services regions released after deferred init, and confirm no ~140 MB leak occurs via free memory reporting.

Typical attack path

  1. Obtain local access or control boot parameters on a target x86 Linux system
  2. Ensure CONFIG_DEFERRED_STRUCT_PAGE_INIT is enabled and total RAM is low (e.g., 512 MB)
  3. Boot the vulnerable kernel so EFI boot services memory is reserved but never released
  4. Observe progressive RAM exhaustion and resulting denial of service

How to detect it

Review dmesg and kernel logs around boot for repeated memblock or EFI boot services messages; compare total free memory reported immediately after boot versus expected values on low-RAM instances; no runtime artifacts are produced after the leak occurs.

What your security team should do

  • Prioritize patching kernel packages on all x86 systems with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y and limited RAM
  • Monitor kernel changelogs for the exact commit that introduces efi_unmap_boot_services()
  • Test patched kernels in staging environments that replicate production memory constraints before broad rollout

The record

In the Linux kernel, the following vulnerability has been resolved: x86/efi: defer freeing of boot services memory efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE and EFI_BOOT_SERVICES_DATA using memblock_free_late(). There are two issue with that: memblock_free_late() should be used for memory allocated with memblock_alloc() while the memory reserved with memblock_reserve() should be freed with free_reserved_area(). More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y efi_free_boot_services() is called before deferred initialization of the memory map is complete. Benjamin Herrenschmidt reports that this causes a leak of ~140MB of RAM on EC2 t3a.nano instances which only have 512MB or RAM. If the freed memory resides in the areas that memory map for them is still uninitialized, they won't be actually freed because memblock_free_late() calls memblock_free_pages() and the latter skips uninitialized pages. Using free_reserved_area() at this point is also problematic because __free_page() accesses the buddy of the freed page and that again might end up in uninitialized part of the memory map. Delaying the entire efi_free_boot_services() could be problematic because in addition to freeing boot services memory it updates efi.memmap without any synchronization and that's undesirable late in boot when there is concurrency. More robust approach is to only defer freeing of the EFI boot services memory. Split efi_free_boot_services() in two. First efi_unmap_boot_services() collects ranges that should be freed into an array then efi_free_boot_services() later frees them after deferred init is complete.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities