CVE-2026-46029: mm/slab: return NULL early from kmalloc_nolock() in NMI on UP

Q: Which systems are affected by this issue?

The issue affects Linux kernel systems built without CONFIG_SMP, meaning uniprocessor (UP) kernels. The vulnerable path requires kmalloc_nolock() to be invoked from NMI context.

Q: What conditions are required to trigger the corruption?

An NMI must interrupt execution while the interrupted context holds the slab allocator's n->list_lock, and the NMI path must call kmalloc_nolock(). On UP kernels, spin_trylock() can then report success despite the lock already being held, allowing allocator re-entry.

Published May 27, 2026

Updated

In the Linux kernel, the following vulnerability has been resolved:

mm/slab: return NULL early from kmallocnolock() 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, kmallocnolock() called from NMI context can re-enter the slab allocator and acquire n->listlock that the interrupted context is already holding, corrupting slab state.

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 getfrompartialnode+0x120/0x4d0 slaballoc+0x8a/0x4c0 kmallocnolocknoprof+0x164/0x310 [...] </NMI>

Fix this by returning NULL early when invoked from NMI on a UP kernel.

Affected Software

4 affected components

Linux Linux kernel

Linux Linux kernel>=6.18<6.18.27

Linux Linux kernel>=6.19<7.0.4

Linux Linux kernel=7.1-rc1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade Linux kernel mm/slub to a version that resolves this vulnerability.
Patch return NULL early from kmalloc_nolock() in NMI on UP
Configuration
Ensure the fix is applied for UP kernels where CONFIG_SMP is not enabled by returning NULL early when kmalloc_nolock() is invoked from NMI on an UP kernel.
Linux kernel (CONFIG_SMP) CONFIG_SMP = disabled (!CONFIG_SMP)

Event History

May 27, 2026

CVE Published

via MITRE·12:56 PM

Data Sourced

via MITRE·12:56 PM

DescriptionSeverity

Data Sourced

via NVD·02:17 PM

RemedyDescriptionSeverityAffected Software

Frequently Asked Questions

Which systems are affected by this issue?

The issue affects Linux kernel systems built without CONFIG_SMP, meaning uniprocessor (UP) kernels. The vulnerable path requires kmalloc_nolock() to be invoked from NMI context.

What conditions are required to trigger the corruption?

An NMI must interrupt execution while the interrupted context holds the slab allocator's n->list_lock, and the NMI path must call kmalloc_nolock(). On UP kernels, spin_trylock() can then report success despite the lock already being held, allowing allocator re-entry.

How can the issue present during testing?

With CONFIG_DEBUG_SPINLOCK enabled on a UP kernel, the slub_kunit test module can trigger a "spinlock trylock failure on UP" BUG. Without that debug configuration, the described outcome is slab-state corruption.

What is the mitigation if the resolved change cannot be applied immediately?

The provided data identifies the affected configuration as UP kernels and the triggering path as kmalloc_nolock() in NMI context. Avoiding that combination is the available mitigation indicated by the vulnerability details.

CVE-2026-46029: mm/slab: return NULL early from kmalloc_nolock() in NMI on UP

Affected Software

Remediation

Event History

Frequently Asked Questions

Which systems are affected by this issue?

What conditions are required to trigger the corruption?

How can the issue present during testing?

What is the mitigation if the resolved change cannot be applied immediately?

Company

Resources

Contact

Frequently Asked Questions

Which systems are affected by this issue?

What conditions are required to trigger the corruption?

How can the issue present during testing?

What is the mitigation if the resolved change cannot be applied immediately?