CVE-2026-85036 in Zephyr
Summary
by MITRE • 11/04/2026
The Bluetooth Classic AVDTP layer defers releasing a session's stream endpoints: bt_avdtp_l2cap_disconnected() in subsys/bluetooth/host/classic/avdtp.c ends with k_work_submit(&session->_release_work), placing the embedded struct k_work on the system work queue's pending list. When the same struct bt_avdtp object is immediately reused for a new signalling connection, the session memory is re-initialized — a2dp_get_connection() in subsys/bluetooth/host/classic/a2dp.c memset()s the whole struct bt_a2dp, and bt_avdtp_l2cap_accept() / bt_avdtp_connect() call k_work_init() on session->_release_work — while that work item is still linked into k_sys_work_q.pending. Zeroing a linked sys_snode_t truncates the list while its tail pointer keeps pointing past the truncation.
The reuse window is deterministic rather than a race. All host RX processing runs on the Bluetooth RX work queue at a cooperative priority (CONFIG_BT_RX_PRIO), while _release_work is submitted to the lower-priority system work queue, so the release handler cannot run until the RX thread blocks. Because l2cap_br_recv() processes every signalling command contained in a single L2CAP signalling PDU back-to-back, a peer can send one PDU holding an L2CAP Disconnection Request for the AVDTP signalling channel followed by a Connection Request for PSM 0x0019; the second command reaches the session-reuse path with the release work provably still queued. The peer must already hold an encrypted AVDTP signalling channel, i.e. be a paired/bonded BR/EDR device.
The result is corruption of the global system work queue's pending list: either the queue silently stops executing any work at all (subsequent submissions are appended to a chain the head can no longer reach, and the orphaned items keep their K_WORK_QUEUED flag forever) or, in the tail variant, the list acquires a self-referencing node that the queue thread spins on. The written values are pointers to other struct k_work objects and are not attacker-controlled, so the impact is a device-wide, reboot-required denial of service rather than a controllable write primitive. Only builds with CONFIG_BT_CLASSIC and CONFIG_BT_A2DP are affected.
The fix is a two-commit unit, and neither commit closes the path on its own. ec822ceed83b adds a pending-release check to bt_avdtp_connect() and bt_avdtp_l2cap_accept(), but the A2DP upper layer's a2dp_get_connection() memset()s the session — including the queued work item's list node and flags — before those checks run, so k_work_busy_get() would observe an already-cleared state. 2bd5ea88c69b closes that by making a2dp_get_connection() itself skip the reuse and return NULL while the release work is still pending, which both callers already handle by rejecting the connection attempt. Apply both commits together; either one alone leaves the device vulnerable.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability resides within the Bluetooth Classic Audio/Video Distribution Transport Protocol layer in Linux kernel subsystems supporting BR/EDR and A2DP profiles. Specifically, it involves a use-after-free style logic error triggered by improper handling of asynchronous work queue items during session teardown and immediate reuse. When an L2CAP connection for the AVDTP signalling channel is disconnected, the function bt_avdtp_l2cap_disconnected schedules a deferred cleanup operation via k_work_submit on the system work queue. This action places a pointer to the release handler into the pending list of the global kernel work queue without immediately executing it. The critical flaw occurs when the underlying session structure is reused for a new connection before this deferred release completes.
The operational impact stems from the deterministic nature of the race condition rather than a traditional timing-based race. All host receive processing operates on the Bluetooth RX work queue at a cooperative priority, while the release work item resides on a lower-priority system work queue. Consequently, the release handler cannot execute until the higher-priority RX thread blocks or yields. An attacker who is already paired and bonded with the device can exploit this by sending a single L2CAP signalling PDU containing two commands: first an L2CAP Disconnection Request for the AVDTP channel, followed immediately by an L2CAP Connection Request for the A2DP protocol service multiplexer. Because these are processed back-to-back within the same packet processing context, the session memory is re-initialized via memset before the deferred release work has a chance to run on its lower-priority queue.
The technical consequence of this sequence is severe corruption of the kernel's global system work queue data structures. During reuse, k_work_init overwrites the embedded list node and flags of the previously queued but not yet executed work item. Since that item remains linked in the pending list with stale pointers, zeroing its contents truncates the doubly-linked list while maintaining a tail pointer that references memory beyond the valid range or creates a self-referencing loop depending on specific memory layout conditions. This results in either silent failure where subsequent work items become unreachable and orphaned, retaining their queued flags indefinitely, or an infinite spin condition within the queue thread due to circular node references.
The security impact is classified as a denial of service requiring a device reboot. The corrupted pointers point to other kernel structures rather than attacker-controlled memory, preventing arbitrary code execution but guaranteeing system instability. This vulnerability affects only configurations enabling both Bluetooth Classic and A2DP support. Mitigation requires applying two specific upstream commits in conjunction; neither patch alone is sufficient because the first commit adds checks that are bypassed by the memset operation performed before those checks execute, while the second commit prevents the session reuse entirely when a release is pending. Security administrators must ensure both patches are applied to fully close this path and restore system integrity against local or proximate Bluetooth-based denial of service attacks.