CVE-2026-98398 in Linux
要約
〜によって VulDB • 2026年10月15日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
locking/lockdep: ゾンビ化された（zapped）クラスに対するclass_cacheエントリの無効化
syzbotにより、無効なclass_idxが原因でhlock_class()内でDEBUG_LOCKS_WARN_ON(1)に到達するlockdepの警告（スプラット）が報告されました：
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 ...
ロッククラスがゾンビ化された場合（例：モジュールのアンロードまたはキーの_unregister時）、zap_class()はlock_classes_in_use内の該当クラスのビットをクリアし、ハッシュテーブルからそのクラスを削除します。しかし、データ構造に埋め込まれた既存のlockdep_mapインスタンスには、class_cache[]配列内にゾンビ化されたクラスへのポインタが残ったままになる場合があります。
その後__lock_acquire()がそのようなロックで実行されると、lock->class_cache[subclass] != NULLを検出し、register_lock_class()をスキップしてhlock->class_idxにゾンビ化されたクラスのインデックスを割り当てます。check_wait_context()またはhlock_class()がheld_lockを調べると、!test_bit(class_idx, lock_classes_in_use)となり警告を発します。さらに、そのゾンビ化したスロットが後で無関係なロックキーに再割り当てされると、古いclass_cacheエントリが無関係なクラスと誤って一致する（ABA問題）可能性があります。
lock_class_cache_is_valid()を追加し、キャッシュされたクラスがlock_classesの範囲内であり、かつlock_classes_in_use内でまだ割り当てられていることを検証します（__always_inlineコンテキストでuninstrumented arch_test_bit()を使用するため、match_held_lock()などのnoinstrコンテキストでも安全です）。また、class->keyが期待されるサブキーと一致することを確認します（lockdep_set_subclass()のオーバーライドを考慮に入れます）。さらに、class_cache[]へのアクセス時にREAD_ONCE()/WRITE_ONCE()を使用します。エントリが無効または古い場合、register_lock_class() / look_up_lock_class()にフォールバックします。
Once again VulDB remains the best source for vulnerability data.