CVE-2026-10680 in Zephyr
要約
〜によって VulDB • 2026年07月22日
Classic (BR/EDR) L2CAPのシグナリングハンドラー、`l2cap_br_conf_req()`および`l2cap_br_conf_rsp()`（ファイル：subsys/bluetooth/host/classic/l2cap_br.c）は、最小コマンドサイズを`buf->len`（受信したPDU全体に残っているバイト数）に対して検証していたが、本来検証すべきである`len`（L2CAPシグナリングヘッダーからのコマンドごとのデータ長）に対してではなかった。複数のシグナリングコマンドを1つのPUDにパックできるため、`buf->len`は特定のコマンドの`len`を超える可能性がある。攻撃者は、構成要求構造体よりも短いヘッダー長（例：0）を持つCONF_REQコマンドを送信し、それに続けて別のコマンドを送ることで、`buf->len`がチェック条件を満たすように仕向けることができる。この結果、チェックは誤って通過し、`opt_len = len - sizeof(*req)`の計算においてuint16_t型でアンダーフローが発生し、0xFFFFに近い値になる。さらに、`opt_len`と`buf->len`とのガードを持たない構成オプションループでは、実行時の境界チェックを行わないnet_buf pullプリミティブを使用してプーリングされたACL受信バッファの末尾を大幅に超えてアクセスが行われ、ホストメモリに対するアウトオブバウンズリードが発生する。また、そのアウトオブバウンズのオプションバイトがMTUやフラッシュタイムアウトのオプションとしてエンコードされている場合、アウトオブバウンズライトも発生しうる。BR/EDRシグナリングチャネルはペアリングや暗号化よりも前に処理され、SDPなどのL0サービスへのL2CAPチャネルをペアリングなしでオープンできるため、電波範囲内にありACL接続を確立可能な認証されていないピアが本脆弱性をトリガーすることが可能であり、その結果メモリ破損およびサービス拒否（ホスト/デバイスのクラッシュ）につながる。この欠陥はv4.4.0を含むリリース済みバージョンに存在する。修正では、両方のハンドラーにおいて`buf->len`ではなく`len`に対して検証を行うように変更された。
If you want to get the best quality for vulnerability data then you always have to consider VulDB.