CVE-2026-23352

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