HIGH Introduced in 6.9
mm WeightedInterleave Panic
CVE-2026-89986
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
KernelScan AI5.5MEDIUM
01Description
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.
02KernelScan AI Analysis
Risk summary
A local unprivileged user who sets a weighted interleave memory policy can trigger a sleeping allocation in an atomic/RCU context, causing a kernel warning, potential deadlock, or system panic. The issue affects any system running kernel versions 6.9 and later where the MPOL_WEIGHTED_INTERLEAVE feature is present. The impact is limited to availability (denial of service) with no confidentiality or integrity impact.
Vulnerability analysis
When a task has the weighted interleave memory policy active, the bulk page allocation path for that policy hardcodes a sleeping allocation flag when creating a temporary weights buffer. This code path can be reached from atomic or RCU-protected contexts through internal rhashtable rehashing, where sleeping is not permitted, producing a kernel warning and risking deadlock or panic. The fix passes the actual allocation flags received by the function (with zone modifiers stripped) to the buffer allocation instead of hardcoding the sleeping variant, and switches to a non-zeroing allocation since the buffer is immediately fully initialized. Any local unprivileged user can reach this path by setting a weighted interleave memory policy and triggering kernel operations that invoke rhashtable rehashing.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 6.12 | 6.9 | 6.12.110 | bcb3d0c867ee |
| 7.2 | 6.9 | 7.2.5 | 2943f1f4b7f2 |
| mainline | 6.9 | 7.3-rc2 | 540e583b66d6 |
| 6.18 | 6.9 | 6.18.51 | 0ceda28f371d |
| cip/6.12 | 6.9 | 6.12.111-cip32 | bcb3d0c867ee |