---
id: "CVE-2026-85033"
kind: "vulnerability"
aliases: ["CVE-2026-85033"]
title: "Zephyr Bluetooth AVRCP: link drop mid-response stalls later responses and leaks buffers"
severity: "medium"
cvss: 4.6
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["avrcp", "bluetooth", "embedded", "runtime", "zephyr"]
not_affected_if: ["avrcp-target-disabled", "no-bluetooth-classic", "unpaired-only"]
published_at: "2026-11-03T14:17:38+00:00"
first_seen_at: "2026-11-03T14:21:08+00:00"
updated_at: "2026-11-03T14:22:06+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-85033", "first_seen_at": "2026-11-03T14:21:08+00:00"}]
---

# Zephyr Bluetooth AVRCP: link drop mid-response stalls later responses and leaks buffers

Zephyr's Bluetooth AVRCP Target code does not release a half-sent vendor-dependent response when the link drops, so the stale state persists on the reused connection slot. A paired nearby peer can stop further AVRCP vendor responses from being sent and leak a buffer each cycle, and a later peer can receive the remainder of the earlier peer's response.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check whether the device firmware is built on Zephyr with Bluetooth Classic AVRCP Target enabled (`subsys/bluetooth/host/classic/avrcp.c` present in the build).
- Compare the Zephyr version against the fixed release in the advisory (unknown from these sources).

## Timeline

- 2026-11-03T14:21:08+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-85033

## Documents

- [advisory] Vendor advisory: github.com https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-2fqc-xhj4-qvp7
- [fix] Patch: github.com https://github.com/zephyrproject-rtos/zephyr/commit/47728746bb52863607f06072c13a0a524ad6b654

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_