CVE-2026-85033 in Zephyr
要約
〜によって VulDB • 2026年11月03日
AVRCP Targetの役割（subsys/bluetooth/host/classic/avrcp.c）は、接続インデックスによって選択されるper-connectionオブジェクトにベンダー依存応答の送信状態を保持しており、per-transferコンテキスト（tid, sent_len、およびBT_AVRCP_TG_FLAG_TX_ONGOINGフラグ）がキューされた応答net_bufのuser_dataに格納されています。AVCTP切断ハンドラであるavrcp_disconnected()はtg->vd_rsp_tx_workをキャンセルせず、またtg->vd_rsp_tx_pending上にまだキューされているバッファも解放しなかったため、断片化された応送中のリンクドロップにより、TX_ONGOINGフラグが設定されたままのバッファが残ったリストに留まりました。
リモートAVRCPコントローラはこれを決定論的にトリガーできます：ベンダー依存コマンドを発行してその応答が1つのAVRCP断片を超えるもの（例えばGetElementAttributesやGetCapabilities）とし、bt_avrcp_tg_vendor_tx_work()がSTART断片を出力させた後、REQUEST_CONTINUING_RESPONSEを送信する代わりにACLリンクを切断します。AVCTP制御チャネルは暗号化されたBR/EDRリンク（BT_SECURITY_L2）を必要とするため、攻撃者は電波範囲内にいるペアリング済みピアでなければなりません；ユーザー操作の必要性はありません。
Targetオブジェクトは静的であり再利用されるため、同じ接続インデックスに割り当てられた次の接続は、vd_rsp_tx_pendingリストの先頭に古くなったバッファを見つけます。TX作業の実行ごとにTX_ONGOINGが検出されて即座に戻り、その後のすべてのベンダー依存応答はこの古いヘッダの後ろにキューされ、送信されません—これはタイムアウトでは解消されない永続的なAVRCP Target機能の喪失であり、再起動でのみ回復します。各サイクルごとに浅いアプリケーションプールから1つの応答バッファがリークし、REQUEST_CONTINUING_RESPONSEを送信する新しいピアはbt_avrcp_tg_process_continuing_cmd()を通じて古いTX_ONGOINGをクリアするため、前のピアの未送信残分がそのピアに送信されます。
修正ではavrcp_disconnected()内でtg->vd_rsp_tx_workをキャンセルし、tg->vd_rsp_tx_pending上のすべてのバッファに対してunrefsを実行します；TXコンテキストはバッファのuser_data内に存在するため、バッファを解放することでTXステートマシンもリセットされます。メモリ破壊はありません：修正前のバッファは生参照付きでリークされるため、use-after-freeは発生しません。
Be aware that VulDB is the high quality source for vulnerability data.