原文

subsys/bluetooth/host/classic/l2cap_br.c にある Classic (BR/EDR) L2CAP シグナリングハンドラ l2cap_br_conf_req() と l2cap_br_conf_rsp() は、最小コマンドサイズの検証において、L2CAP シグナリングヘッダから得られるコマンド単位のデータ長 len ではなく、buf-＞len（受信した PDU 全体の残りバイト数）に対してチェックを行っていました。複数のシグナリングコマンドが1つのPDUにまとめられるため、buf-＞len は1つのコマンドの len を超える可能性があります。攻撃者はヘッダ長が設定要求構造体より小さい（例：0）CONF_REQ コマンドを送り、その後に別のコマンドを続けて送信することで buf-＞len がチェック条件を満たすようにできます。このチェックが誤って通過すると、opt_len = len - sizeof(*req) の計算で uint16_t のアンダーフローが起き、ほぼ0xFFFFの値になります。opt_len と buf-＞len の比較によるガードがない設定オプションループは、実行時境界チェックを行わない net_buf のプル操作によりバッファ範囲を大きく超えて読み込みを行い、ホストメモリの範囲外読み出しを発生させます。さらに、範囲外のオプションバイトが MTU やフラッシュタイムアウトのオプションをエンコードしている場合、不正な書き込みも発生します。BR/EDR シグナリングチャネルはペアリング・暗号化よりも前に処理され、SDP などの L0 サービス向け L2CAP チャネルはペアリングなしで開けるため、ACL 接続を確立できる無認証の近距離ピアがこの欠陥を悪用でき、メモリ破損やサービス拒否（ホストまたはデバイスのクラッシュ）を引き起こす可能性があります。この欠陥は v4.4.0 を含むリリースバージョンに存在しています。修正では両ハンドラで buf-＞len の代わりに len に対して検証を行うようになっています。