---
id: "CVE-2026-79982"
kind: "vulnerability"
aliases: ["CVE-2026-79982"]
title: "Zephyr USB Bluetooth HCI class: buffer overflow lets nearby attacker corrupt memory"
severity: "high"
cvss: 8.8
epss: null
exploited: false
status: "open"
category: "runtime"
products: [{"name": "zephyr", "fixed": ["4.5.0"], "affected": ">= 3.3.0, <= 4.4.2", "ecosystem": "vendor"}]
ecosystems: []
tags: ["bluetooth", "embedded", "raw-hci", "runtime", "usb", "zephyr"]
not_affected_if: ["bt-hci-raw-disabled", "legacy-usb-stack", "no-usb-hci-transport"]
published_at: "2026-10-23T20:17:28+00:00"
first_seen_at: "2026-10-23T21:57:34+00:00"
updated_at: "2026-10-23T23:34:23+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-79982", "first_seen_at": "2026-10-23T21:57:34+00:00"}, {"source": "analyst", "url": null, "first_seen_at": "2026-10-23T23:34:23+00:00"}]
---

# Zephyr USB Bluetooth HCI class: buffer overflow lets nearby attacker corrupt memory

Zephyr's USB Bluetooth HCI class (device_next) copies controller-to-host HCI packets into 64-byte USB slots on full-speed-only builds with no length check. The default build already overruns by 6 bytes at host init (70-byte Read Supported Commands event). A nearby unauthenticated attacker can send larger ACL packets or extended advertising reports. With CONFIG_ASSERT=n the result is memory corruption and possibly code execution. With assertions on it is a panic (DoS). Over-the-air LE triggers apply to full-speed-only builds from v4.2.0; before that, or on high-speed builds, reaching it needs an external BR/EDR controller and BT_BUF_ACL_RX_SIZE >= 508.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- vendor:zephyr affected >= 3.3.0, <= 4.4.2 fixed 4.5.0

## How to check

You are exposed if your build uses the device_next USB stack with the Bluetooth HCI USB class (subsys/usb/device_next/class/bt_hci.c, CONFIG_BT_HCI_RAW over USB) on Zephyr 3.3.0 to 4.4.2. Check 'git describe' of your Zephyr tree and your .config / build config for CONFIG_USBD_BT_HCI and CONFIG_BT_HCI_RAW. Most exposed: full-speed-only USB (USBD_MAX_BULK_MPS = 64) on v4.2.0 or later. Not affected: the legacy USB stack, and builds without the USB HCI class.

## Fix

Move to Zephyr 4.5.0 once released (advisory's projected version; confirm). Until then, cherry-pick commit 0419defd2391 (main) or take the backports on v4.4-branch (PR #117504) / v4.3-branch (PR #117505). Fix: separate bt_hci_tx_pool sized MAX(BT_BUF_ACL_RX_SIZE, BT_BUF_EVT_RX_SIZE). Workaround: do not expose the controller through the USB HCI class (disable it). CONFIG_NET_BUF_HARDENING=y is not an advisory-endorsed mitigation: it only turns the tailroom check from assert-only into a real check, which would fault instead of corrupting memory, and the default build trips it at host init.

## Timeline

- 2026-10-23T21:57:34+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-79982
- 2026-10-23T23:34:23+00:00 analyst — Read Zephyr GHSA-w5px-w97v-c3hj and fix commit 0419def. Affected >=3.3.0 <=4.4.2, patched 4.5.0 (projected, not yet released; backports merged to v4.4-branch #117504 and v4.3-branch #117505). No exploitation or PoC found; no social search (embargo lifted today). CONFIG_NET_BUF_HARDENING is not named as a mitigation by the advisory; it only says add_mem asserts on tailroom unless it is set.

## Documents

- [advisory] GHSA-w5px-w97v-c3hj: OOB write in USB Bluetooth HCI class https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-w5px-w97v-c3hj
- [describes] NVD CVE-2026-79982 https://nvd.nist.gov/vuln/detail/CVE-2026-79982
- [fix] 0419def usb: device_next: bt_hci: size buffers for complete HCI packets https://github.com/zephyrproject-rtos/zephyr/commit/0419defd2391652edc27689d206fcd9c48439d4a

## From the sources

The Bluetooth HCI USB transport class of the new USB device stack, subsys/usb/device_next/class/bt_hci.c, copies every controller-to-host HCI packet into a USB transfer buffer before enqueuing it on an endpoint. bt_hci_tx_sync_in() allocated that buffer from bt_hci_ep_pool, a fixed pool whose slots are only USBD_MAX_BULK_MPS bytes (64 on full-speed-only builds), and then performed net_buf_add_mem(buf, bt_buf->data, bt_buf->len) with no length check. HCI event and ACL buffers are sized by CONFIG_BT_BUF_EVT_RX_SIZE and CONFIG_BT_BUF_ACL_RX_SIZE and can be far larger, so the copy runs past the end of the 64-byte slot into the adjacent slots and into whatever follows the statically allocated pool.

The device runs the local Bluetooth controller in raw HCI mode (CONFIG_BT_HCI_RAW), so the oversized packets originate over the air. With the HCI buffer sizes recommended for full-featured controllers, an unauthenticated attacker within Bluetooth range can supply the overflowing bytes: a connected peer that negotiates Data Length Extension can send ACL fragments up to CONFIG_BT_CTLR_DATA_LENGTH_MAX bytes, and an attacker that merely broadcasts extended advertising data reaches the same path through LE Extended Advertising Report events, which the controller fragments only to CONFIG_BT_BUF_EVT_RX_SIZE. In the stock configuration the overflow is already reached without any radio traffic: the mandatory Read Supported Commands command-complete event is 70 bytes and overruns the 64-byte slot by six bytes on every host initialization.

Because net_buf_add_mem() validates tailroom only through an assertion unless CONFIG_NET_BUF_HARDENING is enabled, builds with CONFIG_ASSERT=n — the usual production setting — silently corrupt memory adjacent to the USB buffer pool with attacker-chosen contents, which on a target without memory protection between subsystems can lead to arbitrary code execution. Builds with assertions enabled fail the assertion instead and panic, giving a remotely triggerable denial of service. The fix introduces a separate bt_hci_tx_pool sized to MAX(BT_BUF_ACL_RX_SIZE, BT_BUF_EVT_RX_SIZE) for the controller-to-host direction while leaving the host-to-device pool at the endpoint packet size, which is already bounds-checked during reassembly.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_