CVE-2026-72491
要約
〜によって VulDB • 2026年08月15日
Linuxカーネルにおいて、以下の脆弱性が修正されました。
net/9p: trans_rdma.cにおけるrdma->stateの競合状態（race condition）を修正する
recv_done()およびp9_cm_event_handler()では、req_lockを取得せずにrdma->stateフィールドが変更されています。一方、rdma_request()はreq_lockスピンロックの下で同じフィールドにアクセスします。この一貫性のないロック処理により、競合状態が発生しています：
- recv_done()はsoftirq完了コンテキスト内で実行され、req_lockの取得なしにrdma->stateをP9_RDMA_FLUSHINGに設定する - p9_cm_event_handler()は複数のポイント（ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED）でreq_lockなしにrdma->stateを変更する - rdma_request()は、rdma->stateの読み取り・変更・書き込み操作を保護するためにspin_lock_irqsave(&rdma->req_lock, flags)を使用している
この競合により、状態遷移が失われる可能性があります。recv_done()またはCMイベントハンドラがFLUSHING/CLOSEDに状態を設定する際、rdma_request()はロックの下で同時に状態のチェックや変更を行っているため、FLUSHINGへの遷移がCLOSINGによって静かに上書きされることがあります。これにより接続ステートマシンが破損し、ティアダウン時にRDMAリクエストオブジェクトに対してuse-after-freeが発生する可能性があります。
recv_done()およびp9_cm_event_handler()におけるrdma->stateの変更すべてにreq_lockによる保護を追加することで修正します。これはすでにrdma_request()で使用されているパターンと一致しています。CMイベントハンドラではspin_lock_irqsave/spin_unlock_irqrestoreを使用します。これは、softirqコンテキストで実行されるrecv_done()との競合が発生する可能性があるためです。
5.5M回以上のFLUSHING書き込みを27M回のイテレーションで行った際、ロック状態が適切である場合（rdma_requestとrecv_done/CMハンドラをシミュレートするために競合させるスレッドを持つカーネルモジュールを使用してテスト）、0件の遷移損失を確認しました。
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.