{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.111-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.2.7-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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:    \u003cIRQ\u003e    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-\u003eclass_cache[subclass] != NULL, skipping register_lock_class() and assigning hlock-\u003eclass_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-\u003ekey 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().",
  "id": "DEBIAN-CVE-2026-98398",
  "modified": "2026-10-15T04:47:21.095285693Z",
  "published": "2026-10-14T14:17:50.760Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-98398"
    }
  ],
  "upstream": [
    "CVE-2026-98398"
  ]
}