CVE-2026-43285

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