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.
Severity
CVSS 3.1
4.6 medium
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L
EPSS
0.2% estimated probability of exploitation activity in the next 30 days; 12th percentile. Scored 2026-11-04. A forecast for this CVE across the internet, not for your own systems.
CISA's assessment (SSVC)
Exploitation: none · Automatable: no · Technical impact: partial, assessed 2026-11-03. From CISA's Vulnrichment in the CVE List: whether it is exploited, whether exploiting it can be automated, and how much control it gives.
Show the promptExplain CVE-2026-85033 for an engineer deciding whether to act. Use https://cve.bz/api/public/cves/CVE-2026-85033?via=ask-ai-copy and https://cve.bz/cve/CVE-2026-85033?via=ask-ai-copy as the source of truth: what is affected and which versions fix it, whether it is in CISA KEV, public exploits, and its EPSS (an internet-wide 30-day estimate of exploitation activity, not a forecast for my systems). If they give no fixed versions, use the CVE record https://cveawg.mitre.org/api/cve/CVE-2026-85033 or the vendor advisory, not third-party mirrors. Tell me how to check whether I am affected and how to verify a fix. Cite the sources and say where they are uncertain.
Opens a third-party assistant; its answer is its own, not cve.bz's. The prompt holds only this CVE's id and public links.