zephyr: Use After Free
CVE-2026-19935 is a high-severity use after free vulnerability in zephyr from Zephyr Project, with a CVSS 3.1 base score of 7.5 out of 10. It can be exploited from the same local network by an unauthenticated attacker, without any action from a user. The record lists version 4.5.0 as the first without the flaw, so updating zephyr to that release or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.18% chance of exploitation within 30 days, which is low compared with other CVEs.
High severity with no evidence of exploitation so far.
What to do
- Update zephyr to 4.5.0 or a later version.
- Read the advisory on github.com for workarounds and exact fixed builds.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Zephyr Project | zephyr | 2.0.0 up to, but not including, 4.5.0 | 4.5.0 |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- AdjacentThe attacker must be on the same local network segment.
- Attack complexity
- HighSuccess depends on conditions outside the attacker's control.
- Privileges required
- NoneNo account or login is needed.
- User interaction
- NoneNo action by a victim is required.
- Scope
- UnchangedImpact stays within the vulnerable component.
- Confidentiality
- HighAll data handled by the component can be read.
- Integrity
- HighData or code can be modified at will.
- Availability
- HighThe component can be taken down completely.
Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Scored by CNA (zephyrproject.org).
Official 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.
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Use After Free
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory belongs to the code that operates on the new pointer.
How developers prevent this class of flaw
- Choose a language that provides automatic memory management.
- When freeing pointers, be sure to set them to NULL once they are freed. However, the utilization of multiple or complex data structures may lower the usefulness of this strategy.
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: total).
- Record last changed materially (score, affected products, status or references).
References
Patches and release notes
Other vulnerabilities in zephyr
- 7.8 High severity
- 7.8 High severity
- 9.1 Critical severity
- 8.3 High severity
- 7.5 High severity
- 7.8 High severity
Recent Use After Free vulnerabilities
- 9.1 Critical severity
- 8.1 High severity
- 9.8 Critical severity
- 8.8 High severity
- 8.8 High severity
- 9.6 Critical severity
Spotted an error? Tell us.