CVE-2026-79982: Out-of-bounds write in the USB Bluetooth HCI transport class when a controller-to-host HCI packet exceeds the bulk endpoint maximum packet size
The Bluetooth HCI USB transport class of the new USB device stack, subsys/usb/devicenext/class/bthci.c, copies every controller-to-host HCI packet into a USB transfer buffer before enqueuing it on an endpoint. bthcitxsyncin() allocated that buffer from bthcieppool, a fixed pool whose slots are only USBDMAXBULKMPS bytes (64 on full-speed-only builds), and then performed netbufaddmem(buf, btbuf->data, btbuf->len) with no length check. HCI event and ACL buffers are sized by CONFIGBTBUFEVTRXSIZE and CONFIGBTBUFACLRXSIZE 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 (CONFIGBTHCIRAW), 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 CONFIGBTCTLRDATALENGTHMAX 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 CONFIGBTBUFEVTRXSIZE. 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 netbufaddmem() validates tailroom only through an assertion unless CONFIGNETBUFHARDENING is enabled, builds with CONFIGASSERT=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 bthcitxpool sized to MAX(BTBUFACLRXSIZE, BTBUFEVTRXSIZE) 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Enable CONFIG_NET_BUF_HARDENING so net_buf_add_mem() validates tailroom instead of relying only on assertions.
Zephyr net_buf CONFIG_NET_BUF_HARDENING = y
Event History
Frequently Asked Questions
Which deployments are exposed?
Devices using the new USB device stack's Bluetooth HCI USB transport class and running the local Bluetooth controller in raw HCI mode (CONFIG_BT_HCI_RAW) are exposed. Full-speed-only builds are particularly affected because the bulk endpoint pool slots are 64 bytes, while configured HCI event and ACL receive buffers can be substantially larger.
Does exploitation require Bluetooth pairing or authentication?
No. An unauthenticated attacker within Bluetooth range can provide oversized data over the air. A connected peer can use Data Length Extension to send large ACL fragments, and extended advertising data can also reach the vulnerable path without a connection.
What must an attacker be able to do?
The attacker needs to be within Bluetooth radio range of the device and cause a controller-to-host HCI packet larger than the USB bulk endpoint maximum packet size. The overflowing content is attacker-supplied and can overwrite adjacent pool slots and memory following the statically allocated pool.