CVE-2026-46035: mm/page_alloc: return NULL early from alloc_frozen_pages_nolock() in NMI on UP
In the Linux kernel, the following vulnerability has been resolved:
mm/pagealloc: return NULL early from allocfrozenpagesnolock() in NMI on UP
On UP kernels (!CONFIGSMP), spintrylock() is a no-op that unconditionally succeeds even when the lock is already held. As a result, allocfrozenpagesnolock() called from NMI context can re-enter rmqueue() and acquire the zone lock that the interrupted context is already holding, corrupting the freelists.
With CONFIGDEBUGSPINLOCK on UP, the following BUG is triggered with the slubkunit test module:
BUG: spinlock trylock failure on UP on CPU#0, kunittrycatch/243 [...] Call Trace: <NMI> dumpstacklvl+0x3f/0x60 dorawspintrylock+0x41/0x50 rawspintrylock+0x24/0x50 rmqueue.isra.0+0x2a9/0xa70 getpagefromfreelist+0xeb/0x450 allocfrozenpagesnolocknoprof+0x111/0x1e0 allocateslab+0x42a/0x500 slaballoc+0xa7/0x4c0 kmallocnolocknoprof+0x164/0x310 [...] </NMI>
Fix this by returning NULL early when invoked from NMI on a UP kernel.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Modify alloc_frozen_pages_nolock() to detect NMI context on a UP kernel (!CONFIG_SMP) and return NULL early when invoked from NMI to avoid re-entering rmqueue and corrupting the freelists.
Linux kernel mm/page_alloc (alloc_frozen_pages_nolock) behavior when invoked from NMI on UP (!CONFIG_SMP) = return NULL early
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The issue affects Linux kernel systems built without CONFIG_SMP, meaning uniprocessor (UP) kernels. The vulnerable path requires allocation through alloc_frozen_pages_nolock() while executing in NMI context.
What access or conditions are required to trigger the problem?
The CVSS vector indicates local access and low privileges are required, with no user interaction. Exploitation depends on an NMI interrupting code that already holds the zone lock, causing the NMI allocation path to re-enter rmqueue().
What is the impact if the condition is triggered?
Re-entering rmqueue() can acquire a zone lock already held by the interrupted context and corrupt memory allocator freelists. The reported security impact is availability loss, and the issue can trigger a spinlock failure when CONFIG_DEBUG_SPINLOCK is enabled.
What mitigation is available before updating?
The described fix makes alloc_frozen_pages_nolock() return NULL when it is called from NMI context on a UP kernel. Systems using SMP-enabled kernels are not the UP configuration described as affected.