CVE-2026-93253

In the Linux kernel, the following vulnerability has been resolved: sched/isolation: Defer freeing of cpumask memblock memory to initcall When testing a linu…

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