CVE-2026-93253 in Linux
Summary
by MITRE • 09/24/2026
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 memblock_free() is called late") to prevent a KASAN UAF bug report [1].
[1] https://lore.kernel.org/lkml/[email protected]/
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The Linux kernel vulnerability addressed in this update involves a premature memory deallocation within the scheduler isolation subsystem, specifically affecting systems configured with the nohz_full boot parameter. The core technical flaw resides in the housekeeping_init function, which is responsible for managing CPU masks used to isolate specific CPUs from periodic timer interrupts and other scheduling overheads during early kernel initialization. When this routine attempts to free memory allocated via memblock—a low-level allocator used before the full virtual memory subsystem is active—it triggers a critical warning because the deferred memory map initialization has not yet completed. This sequence violates the expected lifecycle of reserved memory regions, leading to an invalid operation where the kernel tries to release physical memory pages that are still logically tied to uninitialized or partially initialized data structures in the memory management layer.
From a technical perspective, this issue manifests as a warning generated by memblock.c when __free_reserved_area is invoked before deferred_init_memmap has finished populating the page struct array for all available RAM. The call trace reveals that housekeeping_init calls into memblock_phys_free too early in the boot process, specifically during start_kernel execution on x86_64 architectures. This premature freeing can lead to undefined behavior or kernel panics if the memory is accessed later by subsystems expecting it to remain valid until late initialization phases. The root cause is a timing mismatch between when housekeeping resources are allocated and when they are safely eligible for release, given that memblock relies on underlying page structures being fully established before any physical address ranges can be marked as freeable without risking corruption of the memory map metadata.
The operational impact of this vulnerability includes potential system instability during boot, particularly in environments utilizing CPU isolation features designed for real-time or high-performance computing workloads where nohz_full is enabled. If triggered, it may result in a kernel warning that disrupts normal startup procedures or, in more severe cases involving race conditions with other early-boot allocators, could lead to use-after-free scenarios if the freed memory is subsequently reused before proper initialization checks are enforced by dependent patches such as commit 7c2eee9c1367. This dependency highlights how low-level memory management errors can cascade into security-relevant issues like kernel address space layout randomization bypasses or arbitrary code execution vectors through corrupted page tables if the underlying assumptions about memory state consistency are violated.
To mitigate this vulnerability, the fix implements a deferral mechanism by introducing housekeeping_late_init(), which moves the actual freeing of cpumask memblock memory from early boot to the late initcall stage when all subsystems have properly initialized their internal data structures and the memory map is guaranteed to be complete. This approach utilizes an llist (lockless singly-linked list) to store pointers to the allocated regions, ensuring that deallocation occurs only after deferred_init_memmap has finished its work. By treating the cpumask memblock memory as a node within this list and leveraging non-atomic operations due to the single-threaded nature of early boot code, the solution maintains performance while adhering to strict ordering constraints required by the kernel's memory management subsystems.
This issue aligns with CWE-362, Concurrent Execution using Shared Resource without Proper Synchronization or Locking, as it involves improper handling of shared system resources during concurrent initialization phases where timing dependencies are critical. Additionally, from a defensive security standpoint related to ATT&CK technique T1059 Command and Scripting Interpreter, while not directly exploitable for remote code execution in most standard configurations, the underlying memory corruption potential falls under broader categories of kernel privilege escalation vectors such as those described in CWE-416 Use After Free. System administrators should ensure their kernels are updated to include this patch when deploying nohz_full configurations on x86_64 platforms to prevent boot-time failures and maintain integrity of the scheduler isolation features essential for deterministic latency-sensitive applications.