PT-2026-114377 · Linux · Linux

CVE-2026-98398

·

Published

2026-10-14

·

Updated

2026-10-14

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
locking/lockdep: Invalidate stale class cache entries for zapped classes
syzbot reported a lockdep splat hitting DEBUG LOCKS WARN ON(1) in hlock class() due to an invalid class idx:
WARNING: kernel/locking/lockdep.c:238 at lock acquire+0x382/0x2cf0 kernel/locking/lockdep.c:5203 Workqueue: wg-crypt-wg0 wg packet tx worker RIP: 0010:hlock class kernel/locking/lockdep.c:238 [inline] RIP: 0010:check wait context kernel/locking/lockdep.c:4870 [inline] RIP: 0010: lock acquire+0x389/0x2cf0 kernel/locking/lockdep.c:5203 Call Trace: lock acquire+0x106/0x350 kernel/locking/lockdep.c:5886 raw spin lock+0x2e/0x40 kernel/locking/spinlock.c:173 tcp tsq handler+0x29/0x200 net/ipv4/tcp output.c:1291 tcp tsq workfn+0x384/0x410 net/ipv4/tcp output.c:1325 ...
When a lock class is zapped (e.g. during module unload or key unregistration), zap class() clears the class's bit in lock classes in use and removes it from the class hash table. However, existing lockdep map instances embedded in data structures may still retain a pointer to the zapped class in their class cache[] array.
When lock acquire() subsequently runs on such a lock, it finds lock->class cache[subclass] != NULL, skipping register lock class() and assigning hlock->class idx to the index of the zapped class. When check wait context() or hlock class() inspects the held lock, it finds !test bit(class idx, lock classes in use) and warns. Furthermore, if the zapped slot is subsequently re-allocated to an unrelated lock key, the stale class cache entry would erroneously match the unrelated class (ABA issue).
Add lock class cache is valid() to validate that the cached class is within lock classes bounds, still allocated in lock classes in use (using uninstrumented arch test bit() in always inline context so it is safe in noinstr contexts like match held lock()), and that class->key matches the expected subkey (taking lockdep set subclass() overrides into account). Also use READ ONCE()/WRITE ONCE() when accessing class cache[]. If the entry is invalid or stale, fall back to register lock class() / look up lock class().
Found an issue in the description? Have something to add? Feel free to write us 👾

Related Identifiers

CVE-2026-98398

Affected Products

Linux