CVE Catalog

CVE-2026-98398

Low risk· EPSS 11%
Published: Updated: Translated: NVD NIST

Exploitation Probability (EPSS)

Low risk
0.22%

11th percentile - higher than 11% of all known CVEs

Summary

A bug was fixed in the Linux kernel lockdep mechanism that caused a DEBUG_LOCKS_WARN_ON(1) warning in hlock_class() due to an invalid class_idx. The issue arose because class_cache[] entries in lockdep_map structures could still point to zapped lock classes, leading to incorrect matching or warnings. The fix adds validation of class_cache entries and safely refreshes them.

Risk Assessment

The vulnerability can trigger spurious lockdep warnings and, in extreme cases, erroneous lock class matching (ABA issue), complicating diagnostics and potentially causing system instability during module unload or key unregistration.

Recommendation

Update the Linux kernel to a version containing the fix for CVE-2026-98398. If updating is not possible, avoid frequent module unloading and key unregistration in production environments with lockdep enabled.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

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: <IRQ> 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().

Vulnerability data from NVD (NIST) · CISA KEV · EPSS