CVE-2026-46029: Linux Kernel Race Condition Vulnerability

CVE-2026-46029 Overview

CVE-2026-46029 is a Linux kernel vulnerability in the slab allocator (mm/slab) affecting uniprocessor (UP) kernels built without CONFIG_SMP. The flaw allows kmalloc_nolock() invoked from Non-Maskable Interrupt (NMI) context to re-enter the slab allocator and corrupt internal slab state. The root cause is spin_trylock() behaving as a no-op on UP kernels, unconditionally succeeding even when the lock is already held by the interrupted context. The upstream fix returns NULL early when kmalloc_nolock() is called from NMI on UP kernels.

Critical Impact
An NMI handler can re-enter the slab allocator while n->list_lock is already held, corrupting slab metadata and destabilizing kernel memory management on UP systems.

Affected Products

Linux kernel builds with !CONFIG_SMP (uniprocessor configuration)
Kernel versions including the kmalloc_nolock() slab allocation path
Kernels exercising the slub_kunit test module on UP with CONFIG_DEBUG_SPINLOCK

Discovery Timeline

2026-05-27 - CVE-2026-46029 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-46029

Vulnerability Analysis

The vulnerability resides in the Linux kernel slab allocator path reached via kmalloc_nolock(). On UP kernels, spin_trylock() is compiled as a no-op that unconditionally returns success. When an NMI interrupts a thread that already holds n->list_lock and the NMI handler calls kmalloc_nolock(), the allocator re-enters get_from_partial_node() and acquires the same lock. This re-entrancy corrupts the partial slab list and other allocator structures protected by n->list_lock.

With CONFIG_DEBUG_SPINLOCK enabled, the slub_kunit test module triggers the following diagnostic:

BUG: spinlock trylock failure on UP on CPU#0, kunit_try_catch/243
Call Trace:
 <NMI>
  dump_stack_lvl+0x3f/0x60
  do_raw_spin_trylock+0x41/0x50
  _raw_spin_trylock+0x24/0x50
  get_from_partial_node+0x120/0x4d0
  ___slab_alloc+0x8a/0x4c0
  kmalloc_nolock_noprof+0x164/0x310
 </NMI>

Root Cause

The root cause is an unsafe assumption in kmalloc_nolock() that spin_trylock() reflects actual lock state. On UP kernels the call has no meaningful semantics, allowing the allocator to proceed into a critical section that the interrupted context never released. This produces classic re-entrancy of a non-reentrant data structure.

Attack Vector

Triggering the bug requires execution paths that allocate via kmalloc_nolock() from NMI context on a UP kernel while the slab n->list_lock is held elsewhere. The condition is reachable through kernel test harnesses such as slub_kunit and through legitimate NMI handlers that perform best-effort allocation. The flaw is a kernel stability and memory-safety issue rather than a directly remotely exploitable vector. No public exploit is available.

Detection Methods for CVE-2026-46029

Indicators of Compromise

Kernel BUG: spinlock trylock failure on UP messages referencing do_raw_spin_trylock from an NMI call stack
Kernel oops or panic traces containing kmalloc_nolock_noprof, ___slab_alloc, and get_from_partial_node frames inside an <NMI> block
Unexplained slab corruption reports (SLUB consistency check failures) on UP kernels

Detection Strategies

Audit kernel build configuration for !CONFIG_SMP combined with code paths using kmalloc_nolock() from NMI handlers
Enable CONFIG_DEBUG_SPINLOCK and slub_debug on test kernels to surface re-entrant lock acquisition
Run the slub_kunit test module against UP builds to reproduce the diagnostic before deployment

Monitoring Recommendations

Forward dmesg and /var/log/kern.log to a central log store and alert on spinlock trylock failure and SLUB corruption strings
Monitor kernel crash dumps and kdump artifacts for NMI-originated slab allocator frames
Track deployed kernel versions across the fleet and flag systems still running unpatched UP builds

How to Mitigate CVE-2026-46029

Immediate Actions Required

Apply the upstream kernel commits that return NULL early from kmalloc_nolock() when called from NMI on UP kernels
Identify systems built with !CONFIG_SMP and prioritize them for patching
Rebuild and redeploy any custom or embedded kernels that include the affected slab allocator path

Patch Information

The fix is delivered through the upstream Linux kernel stable tree. Reference commits: Kernel commit 5b31044e, Kernel commit a8d95d27, and Kernel commit d6655320. The patch short-circuits kmalloc_nolock() on UP kernels in NMI context, returning NULL instead of entering the slab fast path.

Workarounds

Build kernels with CONFIG_SMP=y where hardware and workload permit, restoring meaningful spin_trylock() semantics
Avoid invoking kmalloc_nolock() from NMI handlers in out-of-tree kernel modules on UP builds
Disable or remove the slub_kunit test module from production UP kernels to prevent self-induced reproduction

bash

# Verify whether a running kernel is built without SMP
grep CONFIG_SMP /boot/config-$(uname -r)
# Expected on affected kernels:
# # CONFIG_SMP is not set

# Confirm running kernel version after applying the stable update
uname -r