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

mm/slab: do not access current->mems_allowed_seq if !allow_spin

Lockdep complains when get_from_any_partial() is called in an NMI
context, because current->mems_allowed_seq is seqcount_spinlock_t and
not NMI-safe:

================================
WARNING: inconsistent lock state
6.19.0-rc5-kfree-rcu+ #315 Tainted: G N
--------------------------------
inconsistent {INITIAL USE} -> {IN-NMI} usage.
kunit_try_catch/9989 [HC1[1]:SC0[0]:HE0:SE1] takes:
ffff889085799820 (&____s->seqcount#3){.-.-}-{0:0}, at: ___slab_alloc+0x58f/0xc00
{INITIAL USE} state was registered at:
lock_acquire+0x185/0x320
kernel_init_freeable+0x391/0x1150
kernel_init+0x1f/0x220
ret_from_fork+0x736/0x8f0
ret_from_fork_asm+0x1a/0x30
irq event stamp: 56
hardirqs last enabled at (55): [<ffffffff850a68d7>] _raw_spin_unlock_irq+0x27/0x70
hardirqs last disabled at (56): [<ffffffff850858ca>] __schedule+0x2a8a/0x6630
softirqs last enabled at (0): [<ffffffff81536711>] copy_process+0x1dc1/0x6a10
softirqs last disabled at (0): [<0000000000000000>] 0x0

other info that might help us debug this:
Possible unsafe locking scenario:

CPU0
----
lock(&____s->seqcount#3);
<Interrupt>
lock(&____s->seqcount#3);

*** DEADLOCK ***

According to Documentation/locking/seqlock.rst, seqcount_t is not
NMI-safe and seqcount_latch_t should be used when read path can interrupt
the write-side critical section. In this case, do not access
current->mems_allowed_seq and avoid retry.
Published: 2026-05-08
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

In the Linux kernel memory allocator, the counter used to protect slab allocations—current->mems_allowed_seq—is accessed during a hard interrupt (NMI) even though it is not NMI‑safe. The lockdep diagnostics report an inconsistent lock state and a potential deadlock, which can lead to a kernel panic. The vulnerability results from improper locking around a sequence counter that is not designed for use in an NMI context.

Affected Systems

The flaw is present in the Linux mm/slab code path and has been observed in development kernel releases such as 6.19.0‑rc5. Systems running these or earlier kernels that have not incorporated the fix are affected; the CVE does not list a specific version range but references commits that address the issue in the 6.19 series and earlier snapshots.

Risk and Exploitability

No EPSS score is available and the flaw is not listed in CISA’s KEV catalog, indicating a low probability of widespread exploitation. Nonetheless the impact is high if exploited: a triggered NMI or interrupt that re‑enters the slab allocator can cause a deadlock or crash the kernel. The most likely attack vector is the deliberate or accidental generation of NMIs to exercise the unsafe access path; however, no public exploit has been disclosed.

Generated by OpenCVE AI on May 8, 2026 at 18:43 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the kernel patch that guards against accessing current->mems_allowed_seq in an NMI context (see commits 144080a5823b2dbd635acb6decf7ab23182664f3, 353dd9934447b9193643ae1afd938607a74d4915, and efd767ddcef0669bbd33c6a823ea0a88f06d4b29).
  • Until the patch is applied, avoid invoking slab allocation routines from NMI handlers or any interrupt context that might lock seqcount_t objects.
  • Monitor kernel logs for lockdep messages such as "inconsistent lock state" and apply the latest kernel release when it becomes available.

Generated by OpenCVE AI on May 8, 2026 at 18:43 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 08 May 2026 13:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: mm/slab: do not access current->mems_allowed_seq if !allow_spin Lockdep complains when get_from_any_partial() is called in an NMI context, because current->mems_allowed_seq is seqcount_spinlock_t and not NMI-safe: ================================ WARNING: inconsistent lock state 6.19.0-rc5-kfree-rcu+ #315 Tainted: G N -------------------------------- inconsistent {INITIAL USE} -> {IN-NMI} usage. kunit_try_catch/9989 [HC1[1]:SC0[0]:HE0:SE1] takes: ffff889085799820 (&____s->seqcount#3){.-.-}-{0:0}, at: ___slab_alloc+0x58f/0xc00 {INITIAL USE} state was registered at: lock_acquire+0x185/0x320 kernel_init_freeable+0x391/0x1150 kernel_init+0x1f/0x220 ret_from_fork+0x736/0x8f0 ret_from_fork_asm+0x1a/0x30 irq event stamp: 56 hardirqs last enabled at (55): [<ffffffff850a68d7>] _raw_spin_unlock_irq+0x27/0x70 hardirqs last disabled at (56): [<ffffffff850858ca>] __schedule+0x2a8a/0x6630 softirqs last enabled at (0): [<ffffffff81536711>] copy_process+0x1dc1/0x6a10 softirqs last disabled at (0): [<0000000000000000>] 0x0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&____s->seqcount#3); <Interrupt> lock(&____s->seqcount#3); *** DEADLOCK *** According to Documentation/locking/seqlock.rst, seqcount_t is not NMI-safe and seqcount_latch_t should be used when read path can interrupt the write-side critical section. In this case, do not access current->mems_allowed_seq and avoid retry.
Title mm/slab: do not access current->mems_allowed_seq if !allow_spin
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-08T13:11:11.191Z

Reserved: 2026-05-01T14:12:55.999Z

Link: CVE-2026-43285

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-05-08T14:16:35.337

Modified: 2026-05-08T14:16:35.337

Link: CVE-2026-43285

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-05-08T18:45:14Z

Weaknesses

No weakness.