Description

The Bluetooth LE host queues received L2CAP connection-oriented channel (CoC) data for deferred processing through a struct k_work embedded in the channel object (le_chan->rx_work, handler l2cap_rx_process()) whenever the channel uses a dynamic PSM (0x0080-0x00FF). Channel teardown in l2cap_chan_destroy() in subsys/bluetooth/host/l2cap.c cancels the retransmission-timeout work and drains the RX FIFO, but never cancels rx_work. Because that work item was submitted to the system workqueue while HCI receive processing runs on the dedicated Bluetooth RX workqueue (CONFIG_BT_RECV_WORKQ_BT, the default), a queued rx_work item can outlive the channel it points into. A remote, unauthenticated peer with an established CoC channel triggers this by sending a data K-frame immediately followed by an L2CAP Disconnect Request. The K-frame submits rx_work to the system workqueue; because both workqueue threads are cooperative and the Bluetooth RX workqueue runs at the higher priority (K_PRIO_COOP(CONFIG_BT_RX_PRIO) versus CONFIG_SYSTEM_WORKQUEUE_PRIORITY), the pending item cannot run before the following Disconnect Request is processed in le_disconn_req() -> l2cap_chan_del() -> l2cap_chan_destroy(). The stack then invokes the released() callback, which the API documents as meaning the stack has dropped all references and the application may free the channel memory. The application therefore frees or re-accepts into an object that the system workqueue still holds in its pending list. If the memory is freed and reallocated, the workqueue later dereferences a list node and a handler function pointer read from reused memory; if the object is re-used for a later connection, l2cap_chan_add() calls k_work_init() on a still-enqueued work item, corrupting the workqueue's pending list so that unrelated work items are dropped or the queue spins on a looped list. A related variant lets l2cap_rx_process() run concurrently with teardown, racing the net_buf unref of le_chan->_sdu and the clearing of chan->conn. The fix routes the channel RX work to the Bluetooth workqueue - the same context in which every teardown path runs - and adds an explicit k_work_cancel() of le_chan->rx_work in l2cap_chan_destroy(), so no reference to the channel survives the released() callback. Configurations without CONFIG_BT_L2CAP_DYNAMIC_CHANNEL, or that only use SIG-assigned PSMs (EATT 0x0027, OTS 0x0025) which take the inline receive path, are not affected.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-10-11T18:16:59.410Z",
  "pubdate": "2026-10-11T18:16:59.410Z",
  "executiveSummary": "This vulnerability involves a use-after-free and workqueue corruption flaw in the Bluetooth LE host stack of the Zephyr Project. The issue arises due to an improper lifecycle management of L2CAP connection-oriented channel (CoC) objects during asynchronous deferred processing.\nA remote, unauthenticated attacker can exploit this condition by sending a specifically timed sequence of L2CAP K-frame data followed by an L2CAP Disconnect Request. This sequence forces the system to queue a work item that persists beyond the lifespan of the underlying channel object.\nSuccessful exploitation allows an attacker to trigger memory corruption, potentially leading to arbitrary code execution, system instability, or kernel panics. The vulnerability affects Zephyr configurations utilizing dynamic L2CAP PSMs (0x0080-0x00FF).\nBecause the system workqueue and the Bluetooth RX workqueue operate at different priorities and contexts, the deferred processing item can outlive the channel teardown process, leading to the dereferencing of freed memory or the corruption of the kernel workqueue list structure.",
  "technicalDetails": "The root cause of the vulnerability is located in the teardown logic of L2CAP CoC channels within 'subsys/bluetooth/host/l2cap.c'. Specifically, 'l2cap_chan_destroy()' fails to cancel the 'le_chan->rx_work' work item, which is responsible for deferred processing of received L2CAP data for dynamic PSMs.\nThe attack flow begins when an unauthenticated remote peer establishes a CoC channel and transmits an L2CAP K-frame. This submission places 'rx_work' onto the system workqueue. Due to the cooperative nature of the Zephyr scheduler and the priority disparity between the Bluetooth RX workqueue and the system workqueue, the subsequent L2CAP Disconnect Request is processed by 'le_disconn_req()' and 'l2cap_chan_del()' before the pending 'rx_work' can execute.\nDuring channel teardown, 'l2cap_chan_destroy()' invokes the 'released()' callback. This informs the application that the stack has relinquished all references to the channel object, leading the application to free the associated memory or reallocate it. However, the system workqueue retains a pointer to the now-stale 'le_chan' object.\nIf the memory is reallocated, the system workqueue's subsequent attempt to execute 'l2cap_rx_process()' results in a use-after-free scenario. It dereferences an outdated handler function pointer or list node from the reused memory. Furthermore, if the memory is repurposed for a new connection, the subsequent 'l2cap_chan_add()' call invokes 'k_work_init()' on the still-enqueued 'rx_work' item. This operation corrupts the workqueue's internal pending list, causing either the silent dropping of unrelated work items or a kernel infinite loop as the list becomes cyclic.\nA secondary vector exists where 'l2cap_rx_process()' races with the teardown sequence, specifically impacting the handling of 'le_chan->_sdu' and the clearing of 'chan->conn', leading to potential null pointer dereferences or data corruption within the Bluetooth stack context."
}