PatchSiren

PatchSiren cyber security CVE debrief

CVE-2026-46035 Linux CVE debrief

A vulnerability in the Linux kernel's memory management subsystem could allow memory corruption on uniprocessor (UP) systems when Non-Maskable Interrupt (NMI) handlers allocate memory. The issue exists because `spin_trylock()` is a no-op that unconditionally succeeds on UP kernels (`!CONFIG_SMP`), even when the lock is already held. This permits `alloc_frozen_pages_nolock()` called from NMI context to re-enter `rmqueue()` and acquire the zone lock that the interrupted context already holds, corrupting the freelists. The vulnerability was discovered through `CONFIG_DEBUG_SPINLOCK` testing with the `slub_kunit` module, which triggered a BUG report showing the NMI re-entry path. The fix returns NULL early from `alloc_frozen_pages_nolock()` when invoked from NMI on UP kernels, preventing the unsafe lock re-acquisition. This vulnerability affects only UP kernel configurations and requires NMI-triggered memory allocation to manifest.

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

Organizations running uniprocessor Linux systems, embedded Linux deployments on single-core hardware, kernel developers maintaining NMI handlers, and security teams monitoring for memory corruption indicators in kernel logs

Technical summary

On uniprocessor (UP) Linux kernels, `spin_trylock()` unconditionally succeeds even when the lock is held, breaking the safety mechanism intended to prevent NMI re-entrancy in `alloc_frozen_pages_nolock()`. When an NMI interrupts a context holding the zone lock and attempts memory allocation, it can re-acquire the same lock via `rmqueue()`, causing freelist corruption. The vulnerability is confined to UP configurations (`!CONFIG_SMP`) and manifests during NMI-triggered slab allocation paths. The fix adds an early return path that yields NULL when called from NMI context on UP systems, preventing the unsafe lock recursion.

Defensive priority

medium

Recommended defensive actions

  • Apply kernel patches from stable kernel.org commits when available for your distribution
  • Verify kernel configuration: if running UP systems (non-SMP), prioritize patching
  • Monitor kernel logs for BUG: spinlock trylock failure on UP messages as potential indicator of exploitation attempts
  • Consider enabling CONFIG_DEBUG_SPINLOCK on UP test systems to detect similar issues
  • Review NMI handlers in custom kernel modules for memory allocation patterns that could trigger this path

Evidence notes

Vulnerability description confirms UP-specific behavior of spin_trylock() as root cause. Call trace in description shows NMI re-entry through kmalloc_nolock_noprof → ___slab_alloc → allocate_slab → alloc_frozen_pages_nolock_noprof → get_page_from_freelist → rmqueue.isra.0. Fix strategy (early NULL return on NMI+UP) explicitly stated. Three kernel.org stable commits provided as references.

Official resources

2026-05-27