PatchSiren

PatchSiren cyber security CVE debrief

CVE-2026-46029 Linux CVE debrief

A slab allocator re-entrancy vulnerability exists in the Linux kernel's memory management subsystem on uniprocessor (UP) builds. On UP kernels (!CONFIG_SMP), spin_trylock() unconditionally succeeds even when the target lock is already held. When kmalloc_nolock() is invoked from non-maskable interrupt (NMI) context, it can re-enter the slab allocator and acquire n->list_lock that the interrupted context already holds, resulting in slab state corruption. The vulnerability manifests as a BUG: spinlock trylock failure on UP when CONFIG_DEBUG_SPINLOCK is enabled. The fix returns NULL early from kmalloc_nolock() when called from NMI context on UP kernels, preventing the re-entrancy condition.

Vendor
Linux
Product
Unknown
CVSS
Unknown
CISA KEV
Not listed in stored evidence
Original CVE published
2026-05-27
Original CVE updated
2026-05-27
Advisory published
2026-05-27
Advisory updated
2026-05-27

Who should care

Linux kernel maintainers, embedded systems developers using UP kernels, security teams monitoring kernel stability, and organizations running legacy uniprocessor systems or custom kernel builds with CONFIG_SMP disabled.

Technical summary

On uniprocessor (UP) Linux kernel builds, spin_trylock() is implemented as a no-op that always succeeds. The kmalloc_nolock() function, designed for atomic contexts, uses spin_trylock() to acquire n->list_lock in the slab allocator. When called from NMI context on UP, kmalloc_nolock() can execute while the interrupted context already holds n->list_lock. Because spin_trylock() reports success, the NMI handler re-enters the slab allocator and corrupts internal state. The vulnerability is a classic re-entrancy bug where interrupt safety mechanisms fail due to UP-specific lock implementation. The fix adds an early return NULL check for in_nmi() on UP kernels, preventing allocation attempts that would corrupt slab state. This vulnerability does not affect SMP kernels where spin_trylock() properly detects lock contention.

Defensive priority

medium

Recommended defensive actions

  • Apply kernel patches from stable branches (5b31044e649e3e54c2caef135c09b371c2fbcd08, a8d95d274be241ad21f6523bf2d6ba0d7d7e46b7, d66553204a15bdb257d9ef8aca1e12f5fbb910b2)
  • Rebuild kernel with CONFIG_SMP=y if hardware supports multiprocessing to eliminate UP-specific code path
  • Enable CONFIG_DEBUG_SPINLOCK on UP test systems to detect similar locking issues
  • Audit NMI handlers for kmalloc_nolock() usage in custom kernel modules
  • Monitor kernel logs for 'BUG: spinlock trylock failure on UP' messages indicating exploitation attempts

Evidence notes

The vulnerability description is sourced from the official CVE record published 2026-05-27. The fix is confirmed through three stable kernel Git commits. The issue affects UP (uniprocessor) kernel builds specifically, not SMP configurations. The slub_kunit test module can trigger the BUG when CONFIG_DEBUG_SPINLOCK is enabled on UP.

Official resources

2026-05-27