CVE-2026-85033 in Zephyr
요약
\~에 의해 VulDB • 2026. 11. 03.
AVRCP Target 역할(subsys/bluetooth/host/classic/avrcp.c)은 연결 인덱스(get_avrcp_tg())로 선택된 각 연결별 객체에 벤더 의존 응답 전송 상태를 유지하며, 각 트랜잭션 컨텍스트(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 컨트롤러는 이를 결정론적으로 트리거할 수 있습니다: 벤더 의존 명령을 발행하여 그 응답이 하나의 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 목록의 선두에 낡은(stale) 버퍼를 발견합니다. TX 작업이 실행될 때마다 TX_ONGOING이 설정되어 있으므로 즉시 반환되며, 이로 인해 모든 후속 벤더 의존 응답이 낡은 선두 뒤에 큐 되어 전송되지 않습니다 — 이는 시간 초과로 해결되지 않으며 재부팅으로만 복구되는 AVRCP Target 기능의 영구적 손실입니다. 각 사이클마다 얕은 애플리케이션 풀에서 하나의 응답 버퍼가 누수되며, 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 상태 머신을 리셋시킵니다. 메모리 부조작(memory corruption)은 발생하지 않습니다: 수정 전의 버퍼는 살아있는 참조(live reference)와 함께 누수되므로 use-after-free는 발생하지 않습니다.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.