CVE Catalog

CVE-2026-19935

HighCVSS 7.5
Published: Updated: Translated: NVD NIST

Exploitation Probability (EPSS)

Low risk
0.18%

7th percentile - higher than 7% of all known CVEs

Summary

A vulnerability in the Zephyr Bluetooth LE stack allows a remote, unauthenticated attacker to trigger a use-after-free in L2CAP CoC channel handling with dynamic PSMs. By sending a data frame followed by a disconnect request, the attacker can cause the system workqueue to process work referencing a freed channel, leading to memory corruption or workqueue corruption.

Risk Assessment

The risk includes remote code execution or denial of service on devices with Bluetooth LE and dynamic L2CAP channels enabled. The attack requires no authentication, only an established CoC connection, making it especially dangerous in IoT environments.

Recommendation

Update Zephyr immediately to a version containing the fix that routes channel RX work to the Bluetooth workqueue and adds explicit cancellation of rx_work in l2cap_chan_destroy(). If updating is not possible, consider disabling dynamic L2CAP channels (CONFIG_BT_L2CAP_DYNAMIC_CHANNEL) or restricting trusted peers.

Other vulnerabilities in Zephyr

See all
Original NVD description (English source)

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.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS