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.
Published: 2026-10-11
Score: 7.5 High
EPSS: n/a
KEV: No
Impact: Remote code execution via use‑after‑free in the Zephyr Bluetooth host
Action: Immediate Patch
AI Analysis

Impact

A use‑after‑free flaw occurs when a Bluetooth L2CAP connection‑oriented channel (CoC) receives data while the channel is being torn down. The RX work item is submitted to the system workqueue but never cancelled, so the work item can later reference a freed channel object. This leads to memory corruption and, if executed correctly, arbitrary code execution or a denial‑of‑service crash.

Affected Systems

The vulnerability affects the Zephyr RTOS Bluetooth stack, specifically when the configuration enables dynamic L2CAP PSMs (CONFIG_BT_L2CAP_DYNAMIC_CHANNEL) and uses the default Bluetooth RX workqueue. Vendor: Zephyr Project; Product: Zephyr RTOS. Version details are not provided in the advisory.

Risk and Exploitability

According to the CVSS score of 7.5, the flaw is classified as high severity. EPSS data is not available, and the vulnerability is not listed in CISA KEV. A remote, unauthenticated peer with an established CoC channel can trigger the flaw by sending a data K‑frame followed by an L2CAP Disconnect Request, creating a race condition that results in a use‑after‑free. The likelihood of exploitation is considered significant in environments where the affected configuration is active.

Generated by OpenCVE AI on October 11, 2026 at 18:22 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the latest Zephyr RTOS patch that routes channel RX work to the Bluetooth workqueue and cancels the work item in l2cap_chan_destroy().
  • Reconfigure the build to disable dynamic L2CAP channels by setting CONFIG_BT_L2CAP_DYNAMIC_CHANNEL=n, or restrict usage to SIG‑assigned PSMs that use the inline receive path.
  • If a patch or configuration change is not feasible, disable Bluetooth functionality on the affected device to eliminate exposure to the race condition.

Generated by OpenCVE AI on October 11, 2026 at 18:22 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sun, 11 Oct 2026 18:45:00 +0000

Type Values Removed Values Added
First Time appeared Zephyrproject
Zephyrproject zephyr
Vendors & Products Zephyrproject
Zephyrproject zephyr

Sun, 11 Oct 2026 17:30:00 +0000

Type Values Removed Values Added
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.
Title Use-after-free of an L2CAP CoC channel object in the Zephyr Bluetooth host: RX work item is not cancelled on channel teardown
Weaknesses CWE-416
References
Metrics cvssV3_1

{'score': 7.5, 'vector': 'CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H'}

Subscriptions

Zephyrproject Zephyr
cve-icon MITRE

Status: PUBLISHED

Assigner: zephyr

Published:

Updated: 2026-10-11T17:15:03.386Z

Reserved: 2026-08-15T13:31:14.966Z

Link: CVE-2026-19935

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-11T18:16:59.410

Modified: 2026-10-11T18:16:59.410

Link: CVE-2026-19935

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-11T18:30:19Z

Weaknesses