CVE-2026-43285
Received Received - Intake
Race Condition in Linux Kernel Memory Management

Publication date: 2026-05-08

Last updated on: 2026-05-08

Assigner: kernel.org

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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-08
Last Modified
2026-05-08
Generated
2026-06-19
AI Q&A
2026-05-08
EPSS Evaluated
2026-06-18
NVD
CVE-2026-43285
EUVD
EUVD-2026-28555
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel 6.19.0-rc5
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Executive Summary

This vulnerability in the Linux kernel involves improper access to the current->mems_allowed_seq variable when the allow_spin flag is not set. The issue arises because current->mems_allowed_seq is a seqcount_spinlock_t, which is not safe to use in Non-Maskable Interrupt (NMI) contexts.

When the function get_from_any_partial() is called in an NMI context, it leads to inconsistent lock states and potential deadlocks due to unsafe locking scenarios. Specifically, the kernel may attempt to acquire a lock that is already held, causing a deadlock.

The root cause is that seqcount_t is not NMI-safe, and the correct type to use in such interruptible contexts is seqcount_latch_t. The fix avoids accessing current->mems_allowed_seq and prevents retries when allow_spin is false, thereby preventing deadlocks.

Impact Analysis

This vulnerability can cause the Linux kernel to enter a deadlock state when handling certain interrupts, specifically Non-Maskable Interrupts (NMIs).

Such deadlocks can lead to system instability, freezes, or crashes, potentially causing denial of service or requiring a system reboot to recover.

Systems relying on the affected kernel versions may experience degraded reliability and availability due to this issue.

Detection Guidance

This vulnerability manifests as lockdep warnings related to inconsistent lock states when get_from_any_partial() is called in an NMI context. Detection involves monitoring kernel logs for warnings about inconsistent lock states and deadlocks involving seqcount_spinlock_t.

You can check your kernel logs for messages similar to the following warning:

  • WARNING: inconsistent lock state
  • inconsistent {INITIAL USE} -> {IN-NMI} usage

To detect this on your system, you can use the following commands:

  • dmesg | grep -i 'inconsistent lock state'
  • journalctl -k | grep -i 'inconsistent lock state'
  • grep -i 'lockdep' /var/log/kern.log

These commands help identify kernel warnings related to this vulnerability by searching for lockdep or inconsistent lock state messages in kernel logs.

Mitigation Strategies

The vulnerability is caused by accessing current->mems_allowed_seq, which is not NMI-safe, in contexts where it can lead to deadlocks.

Immediate mitigation steps include:

  • Avoid accessing current->mems_allowed_seq in NMI (Non-Maskable Interrupt) contexts.
  • Modify or update kernel code to use seqcount_latch_t instead of seqcount_t when the read path can interrupt the write-side critical section, as seqcount_latch_t is NMI-safe.
  • Apply the patch or update to the Linux kernel version where this issue is resolved.

Since this is a kernel-level issue, the most effective immediate step is to update the Linux kernel to a version that includes the fix for this vulnerability.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-43285. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart