---
id: CVE-2026-85033
title: >-
  Bluetooth Classic AVRCP Target: missing TX cleanup on disconnect permanently
  stalls vendor-dependent responses and leaks them to the next peer
summary: >-
  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…
severity: medium
cvss: 4.6
cvssVector: 'CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L'
cvssSource: cna
cwe:
  - CWE-459
vendor: zephyrproject
product: zephyr
affected:
  - zephyr >= 4.4.0 < 4.5.0
ssvc:
  exploitation: none
  automatable: 'no'
  technicalImpact: partial
  timestamp: '2026-11-03T18:15:37.681298Z'
published: '2026-11-03'
updated: '2026-11-03'
sourceUpdated: '2026-11-03T18:15:47.700Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-85033'
references:
  - url: >-
      https://github.com/zephyrproject-rtos/zephyr/commit/47728746bb52863607f06072c13a0a524ad6b654
    label: Fix commit
  - url: >-
      https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-2fqc-xhj4-qvp7
    label: GHSA-2fqc-xhj4-qvp7
tags:
  - cve.org
epss: 0.00215
epssPercentile: 0.1193
ingestedAt: '2026-11-05T20:33:06.342Z'
---

## Overview

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.

## Affected

- `zephyr >= 4.4.0 < 4.5.0`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.