cve.bz

CVE-2026-85033

4.6 mediumEPSS 0.2%

Medium (4.6). EPSS 0.2% estimated probability of exploitation activity in the next 30 days.

On this page
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.
CWE
CWE-459 Incomplete Cleanup
Published
Modified
Record from
the NVD, synced

Ask an AI about this CVE

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.

Versions

From the CNA's record in the CVE List.

ProductAffected
zephyrproject zephyrfrom 4.4.0 before 4.5.0

References

Check your stackJSON