CVE-2026-89986: mm/mempolicy: fix sleeping allocation in alloc_pages_bulk_weighted_interleave()
In the Linux kernel, the following vulnerability has been resolved:
mm/mempolicy: fix sleeping allocation in allocpagesbulkweightedinterleave()
syzbot reported a sleeping function called from invalid context splat in buckettablealloc().
When rhashtableinsertslow() rehashes the table under rcureadlock(), it calls buckettablealloc(..., GFPATOMIC | GFPNOWARN). If the bucket table allocation uses vmalloc, vmallocnoderangenoprof() invokes vmareaallocpages() -> allocpagesbulkmempolicynoprof() with the passed GFPATOMIC flags.
If the current task has an MPOLWEIGHTEDINTERLEAVE mempolicy, allocpagesbulkweightedinterleave() is called and currently hardcodes GFPKERNEL when allocating the temporary weights array, triggering a mightalloc() splat in atomic/RCU contexts.
Pass the gfp flags (masked with GFPRECLAIMMASK to strip page-allocator zone modifiers like GFPHIGHMEM) received by allocpagesbulkweightedinterleave() to kmalloc() instead of hardcoding GFPKERNEL. Since the weights buffer is immediately initialized in full, kmalloc() is sufficient.
Event History
Frequently Asked Questions
Which systems are most likely to encounter this issue?
Systems using an MPOL_WEIGHTED_INTERLEAVE memory policy are relevant. The problematic path occurs when an rhashtable rehash runs under RCU read-side protection and a bucket-table allocation falls back to vmalloc.
What conditions trigger the warning?
The issue is triggered when the vmalloc allocation reaches alloc_pages_bulk_mempolicy_noprof() with GFP_ATOMIC flags while the current task uses MPOL_WEIGHTED_INTERLEAVE. The weighted-interleave path then allocates its temporary weights array with GFP_KERNEL, which can sleep in an atomic or RCU context.
What does the fix change?
The fix passes the caller's GFP flags, masked with GFP_RECLAIM_MASK, to the temporary weights-array allocation instead of hardcoding GFP_KERNEL. This prevents that allocation from using sleeping-capable flags in the affected context.