CVE-2026-93253

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/isolation: Defer freeing of cpumask memblock memory to initcall<br /> <br /> When testing a linux-next kernel with commit 59bd1d914bb5 ("memblock:<br /> warn when freeing reserved memory before memory map is initialized"),<br /> the following warning was hit when there was a "nohz_full" kernel boot<br /> parameter.<br /> <br /> Cannot free reserved memory because of deferred initialization of the memory map<br /> WARNING: mm/memblock.c:904 at __free_reserved_area+0xde/0xf0, CPU#0: swapper/0/0<br /> :<br /> Call Trace:<br /> <br /> memblock_phys_free+0xcb/0x100<br /> housekeeping_init+0x14c/0x170<br /> start_kernel+0x207/0x450<br /> x86_64_start_reservations+0x24/0x30<br /> x86_64_start_kernel+0xda/0xe0<br /> common_startup_64+0x13e/0x141<br /> <br /> <br /> IOW, we shouldn&amp;#39;t free memblock allocated memory so early<br /> in the boot process when memory map isn&amp;#39;t fully initialized in<br /> deferred_init_memmap().<br /> <br /> Fix it by saving the housekeeping cpumask memblock memory to be<br /> freed into a llist free list in housekeeping_init() and add a new<br /> housekeeping_late_init() helper to defer the actual freeing of memblock<br /> memory to when initcall&amp;#39;s are being processed. The cpumask memblock<br /> memory is treated as a llist_node with the size of a "long" type which<br /> is also smallest cpumask size that can be allocated.<br /> <br /> The non-atomic version of the llist APIs are used as there is no<br /> contention.<br /> <br /> This commit depends on the presence of commit 7c2eee9c1367 ("memblock:<br /> don&amp;#39;t touch memblock arrays when memblock_free() is called late")<br /> to prevent a KASAN UAF bug report [1].<br /> <br /> [1] https://lore.kernel.org/lkml/20260505051821.1107133-1-longman@redhat.com/