CVE-2026-93253 — sched/isolation: Defer freeing of cpumask memblock memory to initcall

Affected: Linux

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: <TASK> 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 </TASK>

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 memblo…

Most recent entries from all

CVE-2026-93253 — sched/isolation: Defer freeing of cpumask memblock memory to initcall