CVE-2026-99012 in Linux
要約
〜によって VulDB • 2026年10月23日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
Bluetooth: ISO: 並行する接続呼び出しの直列化
iso_sock_connect() はソケットロックを取得する前にソケットの状態を確認し、接続設定を行う前にロックを解放します。これにより、2つの呼び出し元がソケットが開いているかバインドされている間に、両方とも承認チェックに通過することが可能です。
呼び出し元Aはルーティング選択のために自らの宛先をコピーできますが、その後に呼び出し元BがAがCIS（Connectionless Inductive Service）に対してバインドまたは接続する前にソケットの宛先を書き換えることができます。その後、Aは自身のリクエスト用に選択されたルートで、Bの宛先を使用します。また、BはAが接続をアタッチしてBT_CONNECTを設定した後も処理を進めることができます。遅延 BIS（Broadcast Inductive Service）セットアップの場合、Bは2番目のBISをバインドし、iso_pi(sk)->conn を上書きすることで、最初の接続のリファレンスと conn->sk の逆参照ポインタが孤立する可能性があります。並行するCISの接続も同様にソケットの接続を書き換えることができます。後続のテardown（切断処理）は現在の接続のみをデタッチするため、古い接続に対するコールバックがソケット解放と競合し、解放されたソケットにアクセスすることがあります。
KASAN は以下を検出しました：
BUG: KASAN: slab-use-after-free in iso_sock_hold+0xf7/0x1b0 Call Trace: iso_sock_hold+0xf7/0x1b0 iso_conn_del+0x7b/0x1d0 iso_connect_cfm+0x186/0x16a0 hci_conn_failed+0x154/0x280 hci_abort_conn_sync+0x3dc/0x7d0 hci_cmd_sync_work+0x173/0x300
タスク121によって割り当てられました： sk_alloc+0x2b/0x6d0 bt_sock_alloc+0x29/0x370 iso_sock_alloc.constprop.0+0x19/0x300 iso_sock_create+0x94/0x100
タスク121によって解放されました： kfree+0x121/0x3c0 __sk_destruct+0x42b/0x540 iso_sock_release+0x29d/0x340 __sock_release+0xa1/0x260
ソケットロックの下で承認チェックを行い、宛先を公開する前に接続操作が進行中であることをマークします。ルーティング検索と接続設定全体を通じてこのフラグを設定したままにし、-EBADFD を返して別の接続を試みることを拒否し、宛先の変更や接続のアタッチを防ぎます。どちらのヘルパー関数が戻った後（失敗時を含む）、フラグをクリアすることで、失敗したセットアップのリトライが可能になります。
ソケットロックは HCI デバイスロックを取得する前に解放する必要があり、BT_CONNECT はアタッチされた接続を必要とするため、別のフラグが必要です。既存の状態遷移と iso_sock_recvmsg() を介した遅延 CIS 完了を維持します。
__iso_chan_add() では、新しいリファレンスを取得したりポインタを公開する前に、既存のソケットのアタッチを拒否し、すべての呼び出し元が接続関連性を保持するようにします。遅延 CIS セットアップのための同一ソケット・同一接続の成功ケースも維持します。BIS セットアップの前にアタッチされたソケットを拒否することで、再利用可能な BIS がアタッチが拒否される前に占有されないようにします。
CIS セットアップでは、iso_conn_add() の前に異なる HCI 接続を拒否し、試行ごとの HCI リファレンスを直接解放します。所有権を持たない iso_conn はデタッチ後も他のリファレンンを保持する可能性があるため、その破棄に依存してそのリファレンスを解放することはできません。
iso_listen_bis() はデバイスロックの下で新しい PA HCI/ISO ペアを作成するため、拒否時に一時的な iso_conn_put() が ISO 候補を解放し、HCI リファレンスを解放します。iso_conn_ready() は接続のない新しく割り当てられた未公開の子を使用しており、ソケット側の拒否は到達不可能になります。
If you want to get the best quality for vulnerability data then you always have to consider VulDB.