Skip to main content

Linux Kernel CVE-2026-46029

| EUVDEUVD-2026-32410 HIGH
2026-05-27 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-272j-64q7-2wx2
Linux Information Disclosure
High
Disputed · 7.0 Vendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Share

Severity by source

Sources disagree (Low–High)
Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67) PRIMARY
7.0 HIGH
AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
SUSE
3.1 LOW
AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Attack Vector
Local
Attack Complexity
High
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
May 30, 2026 - 11:38 vuln.today
CVSS changed
May 30, 2026 - 11:22 NVD
7.0 (HIGH)
Patch available
May 27, 2026 - 19:46 EUVD
CVE Published
May 27, 2026 - 14:17 nvd
HIGH 7.0
CVE Published
May 27, 2026 - 14:17 nvd
UNKNOWN (no severity yet)

DescriptionCVE.org

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

mm/slab: return NULL early from kmalloc_nolock() in NMI on UP

On UP kernels (!CONFIG_SMP), spin_trylock() is a no-op that unconditionally succeeds even when the lock is already held. As a result, kmalloc_nolock() called from NMI context can re-enter the slab allocator and acquire n->list_lock that the interrupted context is already holding, corrupting slab state.

With CONFIG_DEBUG_SPINLOCK on UP, the following BUG is triggered with the slub_kunit test module:

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>

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

AnalysisAI

Slab allocator corruption in the Linux kernel's mm/slab subsystem allows local low-privileged users on uniprocessor (UP, !CONFIG_SMP) builds to potentially corrupt kernel memory state when kmalloc_nolock() is invoked from NMI context. The flaw stems from spin_trylock() being a no-op on UP kernels, allowing re-entry into the slab allocator while n->list_lock is already held by the interrupted context. EPSS is very low (0.02%) and no public exploit has been identified at time of analysis, though an upstream patch is available.

Technical ContextAI

The Linux kernel SLUB/slab allocator uses per-node list_lock spinlocks to protect partial-slab freelists. On uniprocessor builds (!CONFIG_SMP), spin_trylock() degrades to a no-op that always returns success, since the kernel assumes no concurrent CPU contention. However, NMIs (non-maskable interrupts) can preempt any context including one already holding n->list_lock; when kmalloc_nolock() runs from the NMI handler, it re-enters ___slab_alloc → get_from_partial_node and 'successfully' takes the same lock, corrupting allocator metadata. CONFIG_DEBUG_SPINLOCK detects this via the slub_kunit test as a 'spinlock trylock failure on UP' BUG. The fix returns NULL early when kmalloc_nolock() is invoked from NMI context on UP kernels.

RemediationAI

Upgrade to Linux kernel 6.18.27, 7.0.4, 7.1-rc2, or later, applying the stable commits at https://git.kernel.org/stable/c/5b31044e649e3e54c2caef135c09b371c2fbcd08, https://git.kernel.org/stable/c/a8d95d274be241ad21f6523bf2d6ba0d7d7e46b7, and https://git.kernel.org/stable/c/d66553204a15bdb257d9ef8aca1e12f5fbb910b2 (Vendor-released patch: 6.18.27 / 7.0.4 / 7.1-rc2). For systems that cannot immediately upgrade, the most direct workaround is to rebuild the kernel with CONFIG_SMP enabled, which renders the bug unreachable because spin_trylock() will operate correctly - the trade-off is increased footprint and is impractical for genuinely single-CPU embedded targets. Distributions tracking the LTS 6.18.y and 7.0.y series should pick up the fix on next routine kernel update.

Same technique Information Disclosure

View all
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8
CVE-2023-7028 CRITICAL POC
10.0
CVE-2017-0213 HIGH POC
7.3

Vendor StatusVendor

SUSE

Severity: Low
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

CVE-2026-46029 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy