CVE-2026-23352
Received Received - Intake
Memory Leak in Linux Kernel x86 EFI Boot Services Freeing

Publication date: 2026-03-25

Last updated on: 2026-04-24

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-25
Last Modified
2026-04-24
Generated
2026-05-07
AI Q&A
2026-03-25
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 16 associated CPEs
Vendor Product Version / Range
linux linux_kernel 2.6.39.1
linux linux_kernel 3.0
linux linux_kernel From 6.19 (inc) to 6.19.7 (exc)
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel From 6.13 (inc) to 6.18.17 (exc)
linux linux_kernel From 6.2 (inc) to 6.6.130 (exc)
linux linux_kernel From 6.7 (inc) to 6.12.77 (exc)
linux linux_kernel From 5.11 (inc) to 5.15.203 (exc)
linux linux_kernel From 5.16 (inc) to 6.1.167 (exc)
linux linux_kernel From 3.0.1 (inc) to 5.10.253 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-401 The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's handling of EFI boot services memory during system boot. Specifically, the function efi_free_boot_services() incorrectly frees memory using memblock_free_late(), which is intended only for memory allocated with memblock_alloc(), while memory reserved with memblock_reserve() should be freed differently.

Additionally, when the kernel is configured with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y, efi_free_boot_services() is called before the deferred initialization of the memory map is complete. This causes some memory pages to remain unfreed because memblock_free_pages() skips uninitialized pages, leading to a memory leak.

The vulnerability results in a leak of approximately 140MB of RAM on certain systems, such as EC2 t3a.nano instances with limited memory (512MB). The fix involves splitting efi_free_boot_services() into two functions: one to collect memory ranges to be freed, and another to free them after deferred initialization is complete, ensuring proper memory management without causing concurrency issues.


How can this vulnerability impact me? :

This vulnerability can cause a significant memory leak during system boot, leading to reduced available RAM. For systems with limited memory, such as small cloud instances, this leak (around 140MB) can impact system performance or stability by reducing the memory available for applications and processes.

Because the leak occurs early in the boot process, it may affect the overall efficiency and reliability of the system, potentially causing slower boot times or resource exhaustion in memory-constrained environments.


What immediate steps should I take to mitigate this vulnerability?

This vulnerability has been resolved by changing the way EFI boot services memory is freed in the Linux kernel.

The fix involves deferring the freeing of EFI boot services memory by splitting the efi_free_boot_services() function into two parts: efi_unmap_boot_services() which collects ranges to be freed, and efi_free_boot_services() which frees them after deferred initialization is complete.

To mitigate this vulnerability, you should update your Linux kernel to a version that includes this fix.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart