Cloudanix VulnDB

CVE-2026-98398

None

CVSS

—

EPSS

0.2%

Published

Oct 14, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A problem in the Linux kernel's internal locking checks can let attackers trigger crashes or memory errors by reusing outdated lock information after certain components are removed.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Theoretical
Impact
Other
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Stale class_cache pointers in lockdep_map structures reference zapped lock classes after module unload or key unregistration, causing __lock_acquire to assign invalid class_idx values that fail lock_classes_in_use checks or match unrelated classes via ABA reuse.

Why it matters to the business

Kernel lock debugging warnings, potential system instability during network or module operations, and elevated risk of use-after-free exploitation in environments running affected kernels.

How an attack unfolds

An attacker triggers class zapping through module unload or key unregistration, then performs operations like TCP segment queue handling in wg_packet_tx_worker to hit the stale class_cache entry, leading to invalid lock state and possible escalation via the resulting use-after-free condition.

How to fix it

Update to a Linux kernel containing the lock_class_cache_is_valid validation, READ_ONCE/WRITE_ONCE accessors, and fallback to register_lock_class on stale entries; rebuild and reboot all affected systems.

How to confirm the fix worked

Boot with lockdep enabled, exercise module load/unload combined with TCP workload, and confirm absence of DEBUG_LOCKS_WARN_ON splats in dmesg; inspect lockdep.c for the new validation helper.

Typical attack path

  1. Unload or unregister a module or key that zaps a lock class
  2. Trigger network stack activity involving spinlocks such as tcp_tsq_handler
  3. Force __lock_acquire to use the stale class_cache reference
  4. Trigger check_wait_context or hlock_class to hit the invalid class_idx
  5. Exploit the ABA or use-after-free window for memory corruption

How to detect it

Search kernel logs for lockdep warnings mentioning hlock_class, check_wait_context, or invalid class_idx during wg-crypt or tcp_tsq_workfn activity; correlate with module unload events.

What your security team should do

  • Prioritize kernel updates on systems exposing network interfaces or dynamic modules
  • Monitor EPSS trend and re-evaluate if exploit code appears
  • Enable lockdep in test environments to surface similar issues early
  • Review downstream dependents for custom modules that may trigger zapping paths

The record

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

Affected packages

Ecosystem Package Introduced Fixed