CVE-2026-98398 in Linux
Zusammenfassung
von VulDB • 14.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
locking/lockdep: Ungültige Class-Cache-Einträge für gelöschte Klassen (zapped classes) ungültig machen
syzbot meldete einen lockdep-Splat, der DEBUG_LOCKS_WARN_ON(1) in hlock_class() auslöste, aufgrund eines ungültigen 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 ...
Wenn eine Lock-Class gelöscht wird (z. B. während des Entladens eines Moduls oder der De-Registrierung eines Schlüssels), löscht zap_class() das Bit dieser Klasse in lock_classes_in_use und entfernt sie aus der Class-Hash-Tabelle. Bestehende lockdep_map-Instanzen, die in Datenstrukturen eingebettet sind, können jedoch weiterhin einen Zeiger auf die gelöschte Klasse in ihrem class_cache[]-Array behalten.
Wenn __lock_acquire() anschließend mit einer solchen Lock ausgeführt wird, stellt es fest, dass lock->class_cache[subclass] != NULL ist, überspringt register_lock_class() und weist hlock->class_idx dem Index der gelöschten Klasse zu. Wenn check_wait_context() oder hlock_class() die held_lock inspizieren, stellen sie !test_bit(class_idx, lock_classes_in_use) fest und warnen. Darüber hinaus würde ein ungültiger Class-Cache-Eintrag fehlerhaft mit einer unzusammenhängenden Klasse übereinstimmen (ABA-Problem), wenn der gelöschte Slot später für einen anderen Lock-Schlüssel neu zugewiesen wird.
Fügen Sie lock_class_cache_is_valid() hinzu, um zu validieren, dass die zwischengespeicherte Klasse innerhalb der Grenzen von lock_classes liegt, weiterhin in lock_classes_in_use allokiert ist (unter Verwendung von uninstrumentiertem arch_test_bit() im __always_inline-Kontext, sodass es sicher in noinstr-Kontexten wie match_held_lock() ist) und dass class->key mit dem erwarteten Sub-Key übereinstimmt (unter Berücksichtigung der Overrides durch lockdep_set_subclass()). Verwenden Sie außerdem READ_ONCE()/WRITE_ONCE(), wenn auf class_cache[] zugegriffen wird. Wenn der Eintrag ungültig oder veraltet ist, greifen Sie auf register_lock_class() / look_up_lock_class() zurück.
If you want to get best quality of vulnerability data, you may have to visit VulDB.