CVE-2026-89986 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
mm/mempolicy: fix sleeping allocation in alloc_pages_bulk_weighted_interleave()
syzbot reported a sleeping function called from invalid context splat in bucket_table_alloc().
When rhashtable_insert_slow() rehashes the table under rcu_read_lock(), it calls bucket_table_alloc(..., GFP_ATOMIC | __GFP_NOWARN). If the bucket table allocation uses vmalloc, __vmalloc_node_range_noprof() invokes vm_area_alloc_pages() -> alloc_pages_bulk_mempolicy_noprof() with the passed GFP_ATOMIC flags.
If the current task has an MPOL_WEIGHTED_INTERLEAVE mempolicy, alloc_pages_bulk_weighted_interleave() is called and currently hardcodes GFP_KERNEL when allocating the temporary weights array, triggering a might_alloc() splat in atomic/RCU contexts.
Pass the gfp flags (masked with GFP_RECLAIM_MASK to strip page-allocator zone modifiers like __GFP_HIGHMEM) received by alloc_pages_bulk_weighted_interleave() to kmalloc() instead of hardcoding GFP_KERNEL. Since the weights buffer is immediately initialized in full, kmalloc() is sufficient.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel vulnerability identified involves a context violation within the memory policy subsystem, specifically affecting the allocation logic for weighted interleave policies. The issue manifests when the rhashtable infrastructure performs a rehash operation while holding an RCU read lock. During this process, the function bucket_table_alloc is invoked with GFP_ATOMIC flags to ensure non-sleeping behavior appropriate for atomic contexts. However, if the memory allocator resorts to vmalloc due to fragmentation or size constraints, it triggers a chain of calls that eventually reaches alloc_pages_bulk_mempolicy_noprof(). This function checks the current task's memory policy and, in cases where an MPOL_WEIGHTED_INTERLEAVE policy is active, delegates allocation responsibilities to alloc_pages_bulk_weighted_interleave.
The core technical flaw lies within alloc_pages_bulk_weighted_interleave(), which previously hardcoded the use of GFP_KERNEL when allocating a temporary weights array via kmalloc(). This hardcoding creates a critical conflict because GFP_KERNEL allows for sleeping and memory reclaim operations, which are strictly prohibited in atomic contexts protected by RCU read locks. Consequently, this mismatch triggers a might_alloc splat reported by syzbot, indicating that a function capable of sleeping was called from an invalid context where such behavior could lead to deadlocks or system instability. The vulnerability represents a failure to propagate the correct allocation flags through the call stack, resulting in a violation of kernel concurrency rules.
From a classification perspective, this issue aligns with CWE-362, which describes concurrent execution using shared resources with improper synchronization. In the context of ATT&CK techniques, while not an exploit vector for external attackers per se, it relates to T1059 Command and Scripting Interpreter if viewed through the lens of kernel-level script injection or abuse, but more accurately reflects internal system reliability issues often categorized under resource management errors. The improper handling of memory allocation flags in a critical path can lead to denial-of-service conditions by causing kernel panics or hangs when triggered repeatedly under high load or specific policy configurations.
The operational impact of this vulnerability includes potential system crashes, particularly on systems heavily utilizing weighted interleave memory policies for performance optimization. Such instability undermines the reliability of enterprise-grade Linux deployments where consistent uptime is paramount. The fix involves modifying alloc_pages_bulk_weighted_interleave to accept and utilize the GFP flags passed from its caller, specifically masking them with GFP_RECLAIM_MASK to strip zone-specific modifiers like __GFP_HIGHMEM that are inappropriate for kmalloc. By passing these corrected flags instead of hardcoding GFP_KERNEL, the allocation becomes safe for atomic contexts since the weights buffer is immediately initialized in full, making a non-reclaiming allocation sufficient and appropriate.
Mitigation strategies primarily involve applying the upstream kernel patch that corrects this flag propagation logic. For organizations unable to update their kernels immediately, monitoring system logs for might_alloc splats or related oops messages can help identify affected systems. Additionally, administrators should review memory policy configurations; disabling MPOL_WEIGHTED_INTERLEAVE policies on critical production servers may serve as a temporary workaround if the vulnerability cannot be patched promptly, although this may impact performance characteristics dependent on that specific interleaving strategy. Regular kernel updates and adherence to security best practices regarding patch management remain the most effective long-term defense against such internal logic errors.