CVE-2026-85033: falha de média gravidade em zephyrproject zephyr
Bluetooth Classic AVRCP Target: missing TX cleanup on disconnect permanently stalls vendor-dependent responses and leaks them to the next peer
Publicada em
Aviso por e-mail quando ela entrar no KEV, ganhar PoC pública ou subir de nota.
13Vexday Risk Score
Sem sinal de exploração. Nenhum artefato público de exploração conhecido até agora.
ssvc Trackcvss 4.6epss 0.2%
The AVRCP Target role in subsys/bluetooth/host/classic/avrcp.c keeps its vendor-dependent response transmit state in a per-connection object selected by connection index (get_avrcp_tg()), with the per-transfer context (tid, sent_len, and the BT_AVRCP_TG_FLAG_TX_ONGOING flag) stored in the user_data of the queued response net_buf. The AVCTP teardown handler avrcp_disconnected() did not cancel tg->vd_rsp_tx_work and did not release the buffers still queued on tg->vd_rsp_tx_pending, so a link drop in the middle of a fragmented response left the buffer on the list with TX_ONGOING still set.
A remote AVRCP Controller can trigger this deterministically: it issues a vendor-dependent command whose response exceeds one AVRCP fragment (for example GetElementAttributes or GetCapabilities), lets bt_avrcp_tg_vendor_tx_work() emit the START fragment, and then drops the ACL link instead of sending REQUEST_CONTINUING_RESPONSE. The AVCTP control channel requires an encrypted BR/EDR link (BT_SECURITY_L2), so the attacker must be a paired peer within radio range; no user interaction is needed.
Because the Target objects are static and reused, the next connection landing on the same connection index finds the stale buffer at the head of vd_rsp_tx_pending. Every run of the TX work sees TX_ONGOING and returns immediately, so all further vendor-dependent responses queue behind the stale head and are never sent — a persistent loss of AVRCP Target function that no timeout clears and only a reboot recovers. Each cycle also leaks one response buffer from a shallow application pool, and a new peer that sends REQUEST_CONTINUING_RESPONSE clears the stale TX_ONGOING via bt_avrcp_tg_process_continuing_cmd(), causing the un-sent remainder of the previous peer's response to be transmitted to it.
The fix cancels tg->vd_rsp_tx_work and unrefs every buffer on tg->vd_rsp_tx_pending in avrcp_disconnected(); since the TX context lives in the buffer user_data, releasing the buffers also resets the TX state machine. There is no memory corruption: the pre-fix buffer is leaked with a live reference, so no use-after-free arises.
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L
Produtos afetados
zephyrproject · zephyrCVEs relacionadas — zephyrproject zephyr
No mesmo produto, das mais perigosas para as menos.
CVE-2026-13214CRITICALStack buffer overflow in OCPP GetConfiguration key parsingEPSS 0.9%CVE-2026-8023HIGHPath traversal in Zephyr HTTP server static-filesystem resource handler allows unauthenticated remote arbitrary file readEPSS 0.9%CVE-2026-13217MEDIUMNULL-pointer dereference in Zephyr OCPP CALLRESULT parsing via unchecked strtok_r/atoiEPSS 0.7%CVE-2026-10666HIGHStack buffer overflow in `net_ipaddr_parse()` IPv4 address-with-port parsing in `subsys/net/ip/utils.c`EPSS 0.7%CVE-2026-10686MEDIUMMissing hop-limit decrement on IPv6 forwarding path allows unbounded packet looping (DoS) in Zephyr routersEPSS 0.6%CVE-2026-10665HIGHHeap buffer overflow on WireGuard receive path via unbounded incoming packet lengthEPSS 0.6%