Incomplete cleanup in Zephyr AVRCP Target leaves stale vendor responses
Key facts
- Attack vector
- Adjacent network
- Privileges required
- Low
- User interaction
- None
- Attack complexity
- Low
- Impact type
- —
- Confidentiality · integrity · availability
- Low · None · Low
- Fix status
- Fixed
Attack profile from CVSS 3.1 · CNA. Fix status from CNA.
Summary
Zephyr from 4.4.0 before 4.5.0 does not clean up Bluetooth Classic AVRCP Target state when an AVCTP link drops during a fragmented vendor-dependent response. The stale response buffer stays queued and blocks all later vendor-dependent responses on that connection index, and a new peer can receive the unsent remainder of the previous peer's response. CWE-459 applies. A paired peer within radio range can trigger this by dropping the ACL link mid-response, with no user interaction needed.
Written with Claude Haiku 5.5 from the sources below · 2026-11-03
Description from the CNA
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.
Why it matters now
SSVC decision points
CISA ADP · SSVC 2.0.3
- Exploitation
- None
- Automatable
- No
- Technical impact
- Partial
The decision (Track, Attend, Act) also depends on your mission and well-being impact; see CISA's SSVC guide.
Affected products
| Vendor | Product | Affected versions | Fixed in | Status | Source |
|---|---|---|---|---|---|
| zephyrproject | zephyr | 4.4.0 to before 4.5.0 | 4.5.0 | Patch available | CNA |
- zephyr Vendorzephyrproject Affected 4.4.0 to before 4.5.0 Fixed in 4.5.0 Patch available CNA
CPE names Threatist (inferred) · 1
Inferred from how NVD named this product before; not given by a source.
| CPE | Versions | Role | Vendor |
|---|---|---|---|
| cpe:2.3:o:zephyrproject:zephyr:*:*:*:*:*:*:*:* | — | — | zephyrproject |
- cpe:2.3:o:zephyrproject:zephyr:*:*:*:*:*:*:*:* Versions — — ·zephyrproject
Remediation
Zephyr 4.5.0 fixes this issue. The sources list no fixed version for Zephyr releases before 4.4.0 in this record.
Written with Claude Haiku 5.5 from the sources below · 2026-11-03
- Fix · CNA zephyr (zephyrproject) Fixed in 4.5.0
Fixed in the same release
Records fixed by the same vendor advisory or release, as the CNA lists them.
- Release ·
zephyrproject zephyr 4.5.0
2 records Highest priority Priority LOW 2 LOW
Other records, highest priority first
- TI-2026-84251 Use-after-free in Zephyr MCTP over USB binding during class disablePriority LOW 21
Timeline
- 2026-11-03 Threatist record created from CVE-2026-85033
- 2026-11-03 CISA SSVC decision points changed
References
Patch 1
Other 1
More zephyrproject vulnerabilities
- TI-2026-04422 Out-of-bounds read/write in HTTP WebSocket upgrade via non-null-terminated Sec-WebSocket-Key CVSS 3.1CRITICAL 9.8
- TI-2026-01361 dns: memory‑safety issue in the DNS name parser CVSS 3.1CRITICAL 9.8
- TI-2026-09174 Unterminated URI buffer causes out-of-bounds read in LwM2M firmware pull (Package URI) CVSS 3.1CRITICAL 9.1
- TI-2026-09168 Stack buffer overflow in `net_ipaddr_parse()` IPv4 address-with-port parsing in `subsys/net/ip/utils.c` CVSS 3.1CRITICAL 9.8
- TI-2024-09625 net: lib: http_server: Buffer Under-read CVSS 3.1HIGH 8.6
- TI-2021-02863 Usb bluetooth device ACL read cb buffer overflow CVSS 3.1CRITICAL 9.6
Sources
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences