CVE-2026-74513 in Linux
要約
〜によって VulDB • 2026年08月15日
Linuxカーネルにおいて、以下の脆弱性が修正されました。
dibs: ループバックアタッチ/デタッチ/_unregister時の dmb_node における use-after-free を修正
dibs_lo_attach_dmb()、dibs_lo_detach_dmb()、および dibs_lo_unregister_dmb() は、dmb_ht_lock の下で dmb_node を検索し、ロックを解放してからノードの参照カウントに対して操作を行います。その間（ウィンドウ中）、ノードが生きていることを保証するものは何もありません：__dibs_lo_unregister_dmb() はライトロックの下でハッシュテーブルからノードを削除し、直ちにそれを解放します。
そのため、並行して発生した最終的な put 処理により、検索と参照カウント操作の間にノードが解放される可能性があります：
CPU0 (attach) CPU1 (所有者による unregister)
read_lock_bh(&dmb_ht_lock) find dmb_node (refcnt == 1) read_unlock_bh(&dmb_ht_lock) refcount_dec_and_test() 1 -> 0 write_lock_bh(&dmb_ht_lock) hash_del(&dmb_node->list) write_unlock_bh(&dmb_ht_lock) kfree(dmb_node) refcount_inc_not_zero(&dmb_node->refcnt) <-- use-after-free
デタッチおよび unregister パスにおける refcount_dec_and_test() の呼び出しでも、同様のウィンドウが存在します。
ハッシュテーブルのメンバーシップと参照カウント遷移を互いに対してアトミックにすることで、この競合条件（race condition）構造的に解消しました：
- unregister および detach パスの両方で、最終的な refcount_dec_and_test() と hash_del() を単一の dmb_ht_lock ライト側クリティカルセクション内で実行します。ノードの解放はロックが解除された後に行われますが、これは安全です。なぜなら、参照カウントがゼロに達したノードはハッシュテーブルから削除されており、もはや検索できないためです。
- これにより、「ハッシュテーブル内に見つかった任意のノードは少なくとも1つの参照を保持しており、最終的な参照はライトロックの下でのみ解放される」という不変条件（invariant）が確立されます。これにより、dibs_lo_attach_dmb() はリードロックを保持したまま単純な refcount_inc() で参照を取得できるようになり、refcount_inc_not_zero() は不要になります。
__dibs_lo_unregister_dmb() はハッシュテーブルにアクセスしなくなり、それに伴って dibs_lo_free_dmb() にリネームされました。
注：コミット cc21191b584c ("dibs: Move data path to dibs layer") によりコードが現在の位置へ移動しました；この競合条件はそれ以前にコミット c3a910f2380f ("net/smc: implement DMB-merged operations of loopback-ism") によって導入されました。
ISM および dibs ループバック経由で SMC-D をテスト済みです。
If you want to get best quality of vulnerability data, you may have to visit VulDB.