CVE-2026-93253: sched/isolation: Defer freeing of cpumask memblock memory to initcall
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 "nohzfull" kernel boot parameter.
Cannot free reserved memory because of deferred initialization of the memory map WARNING: mm/memblock.c:904 at freereservedarea+0xde/0xf0, CPU#0: swapper/0/0 : Call Trace: <TASK> memblockphysfree+0xcb/0x100 housekeepinginit+0x14c/0x170 startkernel+0x207/0x450 x8664startreservations+0x24/0x30 x8664startkernel+0xda/0xe0 commonstartup64+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 deferredinitmemmap().
Fix it by saving the housekeeping cpumask memblock memory to be freed into a llist free list in housekeepinginit() and add a new housekeepinglateinit() helper to defer the actual freeing of memblock memory to when initcall's are being processed. The cpumask memblock memory is treated as a llistnode 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 memblockfree() is called late") to prevent a KASAN UAF bug report [1].
[1] https://lore.kernel.org/lkml/20260505051821.1107133-1-longman@redhat.com/
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems booted with the "nohz_full" kernel parameter are identified as triggering the warning. The issue occurs during early boot while the memory map is still undergoing deferred initialization.
How can I tell whether a system is affected?
Affected systems may log "Cannot free reserved memory because of deferred initialization of the memory map" and a WARNING at mm/memblock.c:904. The call trace includes memblock_phys_free(), housekeeping_init(), and start_kernel().
What can be done if the kernel fix cannot be deployed immediately?
Avoid booting with the "nohz_full" kernel parameter where operationally feasible. The provided fix defers freeing the housekeeping cpumask memblock allocation until initcalls are being processed.