ZephyrProject Zephyr up to 4.4.2 L2CAP l2cap.c l2cap_rx_process rx_work use after free
| CVSS Meta Temp Score | Current Exploit Price (≈) | CTI Interest Score |
|---|---|---|
| 8.5 | $0-$5k | 1.19+ |
Summary
A vulnerability classified as very critical was found in ZephyrProject Zephyr up to 4.4.2. This vulnerability affects the function l2cap_rx_process of the file subsys/bluetooth/host/l2cap.c of the component L2CAP. Such manipulation of the argument rx_work leads to use after free.
This vulnerability is listed as CVE-2026-19935. The attack may be performed from remote. There is no available exploit.
A patch should be applied to remediate this issue.
Details
A vulnerability, which was classified as very critical, has been found in ZephyrProject Zephyr up to 4.4.2. Affected by this issue is the function l2cap_rx_process of the file subsys/bluetooth/host/l2cap.c of the component L2CAP. The manipulation of the argument rx_work with an unknown input leads to a use after free vulnerability. Using CWE to declare the problem leads to CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code. Impacted is confidentiality, integrity, and availability. CVE summarizes:
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.
The advisory is available at github.com. This vulnerability is handled as CVE-2026-19935 since 08/15/2026. The exploitation is known to be easy. The attack may be launched remotely. No form of authentication is required for exploitation. Technical details are known, but there is no available exploit. The structure of the vulnerability defines a possible price range of USD $0-$5k at the moment (estimation calculated on 10/11/2026).
Applying the patch 22896cb8d6f23feffe4b637119fb3e974ac3bed8 is able to eliminate this problem.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Product
Type
Vendor
Name
Version
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔒VulDB Reliability: 🔍
CVSSv3
VulDB Meta Base Score: 8.8VulDB Meta Temp Score: 8.5
VulDB Base Score: 10.0
VulDB Temp Score: 9.5
VulDB Vector: 🔒
VulDB Reliability: 🔍
CNA Base Score: 7.5
CNA Vector (zephyr): 🔒
CVSSv2
| AV | AC | Au | C | I | A |
|---|---|---|---|---|---|
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| Vector | Complexity | Authentication | Confidentiality | Integrity | Availability |
|---|---|---|---|---|---|
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Reliability: 🔍
Exploiting
Class: Use after freeCWE: CWE-416 / CWE-119
CAPEC: 🔒
ATT&CK: 🔒
Physical: No
Local: No
Remote: Yes
Availability: 🔒
Status: Not defined
Price Prediction: 🔍
Current Price Estimation: 🔒
| 0-Day | Unlock | Unlock | Unlock | Unlock |
|---|---|---|---|---|
| Today | Unlock | Unlock | Unlock | Unlock |
Threat Intelligence
Interest: 🔍Active Actors: 🔍
Active APT Groups: 🔍
Countermeasures
Recommended: PatchStatus: 🔍
0-Day Time: 🔒
Patch: 22896cb8d6f23feffe4b637119fb3e974ac3bed8
Timeline
08/15/2026 CVE reserved10/11/2026 Advisory disclosed
10/11/2026 VulDB entry created
10/11/2026 VulDB entry last update
Sources
Advisory: github.comStatus: Confirmed
CVE: CVE-2026-19935 (🔒)
GCVE (CVE): GCVE-0-2026-19935
GCVE (VulDB): GCVE-100-416738
Entry
Created: 10/11/2026 19:40Changes: 10/11/2026 19:40 (68)
Complete: 🔍
Cache ID: 216::103
If you want to get best quality of vulnerability data, you may have to visit VulDB.
No comments yet. Languages: en.
Please log in to comment.