CVE-2026-19939: Bluetooth Classic AVDTP: stale timeout work on signalling-channel disconnect leads to kernel timeout-list corruption
The AVDTP signalling layer arms a 6-second command timeout (AVDTPTIMEOUT) in avdtpsendcmd() whenever the local device issues an AVDTP request. Every response handler in subsys/bluetooth/host/classic/avdtp.c cancels session->timeoutwork before clearing the pending request, but btavdtpl2capdisconnected() only cleared session->req and left the delayable work armed. The struct btavdtp session is the first member of struct bta2dp, whose instances live in a static per-connection array, and a2dpgetconnection() in subsys/bluetooth/host/classic/a2dp.c wipes a slot with memset() as soon as session->brchan.chan.conn is NULL — which the L2CAP layer arranges immediately after the disconnect callback returns.
A remote Bluetooth BR/EDR peer triggers the condition by opening the AVDTP signalling channel, letting the local application issue an AVDTP procedure (the standard A2DP flow issues bta2dpdiscover() from the connected callback), then tearing the signalling channel down without responding and re-opening it within the remaining timeout window. The reconnect reaches a2dpaccept() → a2dpgetconnection(), which zeroes the whole struct bta2dp while the work item's struct timeout is still linked into the kernel's global timeout list. Both the disconnect and the reconnect instants are chosen by the attacker, so no race has to be won; an encrypted BR/EDR link is required, and CONFIGBTA2DP (experimental) must be enabled.
With the default CONFIGTIMEOUTBACKENDDLIST backend the kernel decides a timeout is inactive by testing whether its list node is linked, so after the memset() the kernel treats a node that is still on the global timeout list as free: the announce path pops a node whose links and handler pointer are NULL, and the next btworkreschedule() on the recycled session re-inserts the same node into a list that already contains it. The consequence is corruption of the single kernel data structure every timer, timeslice and sleep depends on — writes through zeroed or stale list pointers and a NULL handler dispatch — producing a system-wide crash or hang rather than a fault confined to the A2DP session.
The fix cancels session->timeoutwork at the top of btavdtpl2capdisconnected() and moves kworkinitdelayable() from avdtpsendcmd() to the session-establishment paths btavdtpconnect() and btavdtpl2capaccept(), so the work item is always initialized before a disconnect callback can run.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Update the AVDTP implementation to cancel session->timeout_work at the top of bt_avdtp_l2cap_disconnected(), and move k_work_init_delayable() from avdtp_send_cmd() to the session-establishment paths bt_avdtp_connect() and bt_avdtp_l2cap_accept().
Event History
Frequently Asked Questions
Which deployments are exposed?
Systems using Zephyr's Bluetooth Classic AVDTP/A2DP signalling path are exposed when a remote BR/EDR peer can connect to the AVDTP signalling channel. The vulnerable sequence requires the local device to issue an AVDTP request during that connection.
What must a remote peer do to trigger the condition?
The peer opens the AVDTP signalling channel, waits for the local application to issue an AVDTP procedure, then disconnects without responding. It must reconnect within the remaining 6-second AVDTP command-timeout window so that the connection slot is reused while the prior timeout work remains armed.
Is a custom AVDTP procedure needed for the local device to issue the request?
No. The described standard A2DP flow calls bt_a2dp_discover() from the connected callback, which issues an AVDTP procedure and can satisfy this prerequisite.