CVE-2026-23352Medium· 5.5▾ SunlitIn 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_…
▾ Sunlit zone — Low / medium · no exploitation signal
impact 30.3 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Oct 15.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via NVD
Last analysed / modified upstream
0.1%
0.1% → 0.1%
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.
linux_kernel >= 3.0.1, < 5.10.253linux_kernel >= 5.11, < 5.15.203linux_kernel >= 5.16, < 6.1.167linux_kernel >= 6.2, < 6.6.130linux_kernel >= 6.7, < 6.12.77linux_kernel >= 6.13, < 6.18.17linux_kernel >= 6.19, < 6.19.7linux_kernel = 2.6.39.1linux_kernel = 3.0linux_kernel = 7.0Upgrade past the affected range:
linux_kernel 6.19.7Connected by shared product, vendor, weakness, or advisory.
CVE-2022-3629Low· 2.6A vulnerability was found in Linux Kernel
CVE-2022-3633Low· 3.5A vulnerability classified as problematic has been found in Linux Kernel
CVE-2022-3524Medium· 4.3A vulnerability was found in Linux Kernel
CVE-2022-1012High· 8.2A memory leak problem was found in the TCP source port generation algorithm in net/ipv4/tcp.c due to the small table perturb size
CVE-2022-26878Medium· 5.5drivers/bluetooth/virtio_bt.c in the Linux kernel before 5.16.3 has a memory leak (socket buffers have memory allocated but not freed).
CVE-2021-4135Medium· 5.5A memory leak vulnerability was found in the Linux kernel's eBPF for the Simulated networking device driver in the way user uses BPF for the device such that function nsim_map_alloc_elem being called