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

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

mm/slab: do not access current->memsallowedseq if !allowspin

Lockdep complains when getfromanypartial() is called in an NMI context, because current->memsallowedseq is seqcountspinlockt and not NMI-safe:

================================ WARNING: inconsistent lock state 6.19.0-rc5-kfree-rcu+ #315 Tainted: G N -------------------------------- inconsistent {INITIAL USE} -> {IN-NMI} usage. kunittrycatch/9989 [HC1[1]:SC0[0]:HE0:SE1] takes: ffff889085799820 (&s->seqcount#3){.-.-}-{0:0}, at: slaballoc+0x58f/0xc00 {INITIAL USE} state was registered at: lockacquire+0x185/0x320 kernelinitfreeable+0x391/0x1150 kernelinit+0x1f/0x220 retfromfork+0x736/0x8f0 retfromforkasm+0x1a/0x30 irq event stamp: 56 hardirqs last enabled at (55): [<ffffffff850a68d7>] rawspinunlockirq+0x27/0x70 hardirqs last disabled at (56): [<ffffffff850858ca>] schedule+0x2a8a/0x6630 softirqs last enabled at (0): [<ffffffff81536711>] copyprocess+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, seqcountt is not NMI-safe and seqcountlatcht should be used when read path can interrupt the write-side critical section. In this case, do not access current->memsallowedseq and avoid retry.