Read the docs
TI-2026-84252 Aliases CVE-2026-85033

Incomplete cleanup in Zephyr AVRCP Target leaves stale vendor responses

Priority LOW 21CWE-459Published · Updated

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

Exploitation None reported CISA SSVC · not in CISA KEV
EPSS 0.00215 11th percentileScored 2026-11-07
Fix Fixed zephyr (zephyrproject): 4.5.0

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

VendorProductAffected versionsFixed inStatusSource
zephyrprojectzephyr4.4.0 to before 4.5.04.5.0Patch availableCNA
  • 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.

CPEVersionsRoleVendor
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

  1. 2026-11-03 Threatist record created from CVE-2026-85033
  2. 2026-11-03 CISA SSVC decision points changed

References

  • 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
See all 341 →

Sources

This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences