# CVE-2026-19739: Bluetooth LE controller leaks a retained RX node when an unexpected LL Control PDU arrives during a Connection Update

> An unauthenticated remote attacker can cause a denial of service in Zephyr RTOS Bluetooth controllers by triggering a memory leak that exhausts the RX buffer pool.

- **Severity:** Medium 6.5 (`CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** No
- **Published:** 11 Oct 2026
- **Updated:** 16 Oct 2026
- **Also known as:** GHSA-84v8-vgp5-4vc9

## What is CVE-2026-19739?

CVE-2026-19739 is a medium-severity denial of service vulnerability in zephyrproject zephyr, published on 11 Oct 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official description

The Bluetooth Link Layer control procedure code in subsys/bluetooth/controller/ll_sw/ull_llcp_conn_upd.c retains the received RX node while a Connection Update / Connection Parameter procedure waits for its instant, so the node can later carry the host notification (llcp_rx_node_retain(), which marks it NODE_RX_TYPE_RETAIN and thereby suppresses the normal recycling in ull.c). The default: arm of llcp_rp_cu_rx() and llcp_lp_cu_rx() — the "invalid PDU, terminate the connection" path — completed the procedure without releasing that retained node. llcp_rr_check_done() then dequeued and freed the procedure context with ctx->node_ref.rx still pointing at the retained node, dropping the last reference to it.

A peer device in radio range can reach this without pairing, bonding, or encryption. Against a peripheral, the peer sends a well-formed LL_CONNECTION_UPDATE_IND with an instant a few connection events in the future (the node is retained and the procedure enters RP_CU_STATE_WAIT_INSTANT), then, before the instant is reached, sends any other LL Control PDU such as LL_LENGTH_REQ. ull_cp_rx() routes that PDU into the active remote Connection Update procedure, which takes the invalid-PDU path. The central role is reachable symmetrically after accepting an LL_CONNECTION_PARAM_REQ, and the local-procedure variant is reachable with LL_REJECT_IND.

With CONFIG_BT_CTLR_ASSERT_DEBUG enabled (its default), the resulting state violates the invariant asserted in llcp_rr_check_done(), so the two-PDU sequence produces an immediate fatal error in the controller. With those asserts disabled, each occurrence permanently loses one node from the controller's small fixed RX pool (sized from CONFIG_BT_CTLR_RX_BUFFERS, which defaults to 1); repeating the sequence across reconnections exhausts the pool, after which the link-layer receive path operates on a NULL node. The impact is an unauthenticated, remotely triggerable denial of service persisting until reboot; there is no memory-disclosure or memory-corruption consequence, since the leaked node simply becomes unreachable.

Weakness: CWE-772 (Missing Release of Resource after Effective Lifetime), CWE-617 (Reachable Assertion), CWE-459 (Incomplete Cleanup), CWE-401 (Missing Release of Memory after Effective Lifetime)

## Which versions are affected by CVE-2026-19739?


## How do I fix CVE-2026-19739?

No fix has been published for CVE-2026-19739 yet. Limit exposure of the affected software until one is available.

## Is CVE-2026-19739 being exploited?

There is no known exploitation of CVE-2026-19739 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-19739 and fix it if it is affected.

What it is: CVE-2026-19739 is a medium-severity denial of service vulnerability in zephyrproject zephyr, published on 11 Oct 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-19739 in the wild and no public exploit code.

Affected product: zephyrproject zephyr. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-19739/ (Markdown: https://insights.sbomify.com/CVE-2026-19739/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-19739
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-19739
- OSV: https://osv.dev/vulnerability/CVE-2026-19739

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-19739/
Summaries are generated and may contain mistakes; the official description above is the record.