bt_hci_le_per_adv_report_common() in subsys/bluetooth/host/scan.c handles the HCI_LE_Periodic_Advertising_Report (and _v2) event. It verified that the fixed event header was present and that the controller-declared Data_Length fits the tailroom of the periodic-sync reassembly buffer, but never checked that the event actually carried as many data bytes as evt->length claims. Both reassembly paths — DATA_STATUS_PARTIAL, and DATA_STATUS_COMPLETE while a chain is already in progress — then called net_buf_simple_add_mem(&per_adv_sync->reassembly, buf->data, evt->length), copying up to 255 bytes starting past the end of the event's real payload.
The Data_Length field originates in the HCI controller, so the flaw is reachable in host-only/split builds where the controller is a separate part reached over H4 UART, SPI, USB or an inter-core IPC transport: a malicious, compromised or buggy controller (or an attacker able to inject on that link) can send a report declaring a length larger than the event payload. The generic event dispatcher in subsys/bluetooth/host/hci_core.c only enforces a per-event minimum length and never cross-checks the subevent's internal length field, so nothing else catches it. Builds using Zephyr's own in-image controller are not affected, because the controller always emits a length matching the bytes it appends.
Exploitation additionally requires CONFIG_BT_PER_ADV_SYNC with CONFIG_BT_PER_ADV_SYNC_BUF_SIZE > 0 (the option defaults to 0, which compiles the reassembly block out; LE Audio broadcast-sink and Public Broadcast Profile applications that reassemble fragmented periodic advertising data set it), and an established periodic advertising sync.
The consequence is an out-of-bounds read of adjacent HCI RX-pool memory — including stale contents of previously received HCI events — which is copied into the reassembly buffer and then delivered to every registered bt_le_per_adv_sync_cb.recv listener as if it were received advertising data, so the disclosed memory becomes application-visible and may be forwarded off-device. The write side remains in bounds because the tailroom check uses the same length value, so there is no memory corruption; impact is limited to information disclosure and undefined behaviour on the over-read. The fix drops any report whose declared length exceeds the remaining event payload, matching the guard already present in the extended and legacy advertising report handlers.
The Data_Length field originates in the HCI controller, so the flaw is reachable in host-only/split builds where the controller is a separate part reached over H4 UART, SPI, USB or an inter-core IPC transport: a malicious, compromised or buggy controller (or an attacker able to inject on that link) can send a report declaring a length larger than the event payload. The generic event dispatcher in subsys/bluetooth/host/hci_core.c only enforces a per-event minimum length and never cross-checks the subevent's internal length field, so nothing else catches it. Builds using Zephyr's own in-image controller are not affected, because the controller always emits a length matching the bytes it appends.
Exploitation additionally requires CONFIG_BT_PER_ADV_SYNC with CONFIG_BT_PER_ADV_SYNC_BUF_SIZE > 0 (the option defaults to 0, which compiles the reassembly block out; LE Audio broadcast-sink and Public Broadcast Profile applications that reassemble fragmented periodic advertising data set it), and an established periodic advertising sync.
The consequence is an out-of-bounds read of adjacent HCI RX-pool memory — including stale contents of previously received HCI events — which is copied into the reassembly buffer and then delivered to every registered bt_le_per_adv_sync_cb.recv listener as if it were received advertising data, so the disclosed memory becomes application-visible and may be forwarded off-device. The write side remains in bounds because the tailroom check uses the same length value, so there is no memory corruption; impact is limited to information disclosure and undefined behaviour on the over-read. The fix drops any report whose declared length exceeds the remaining event payload, matching the guard already present in the extended and legacy advertising report handlers.
Metrics
Affected Vendors & Products
No data.
No data.
No data.
No data.
Advisories
No advisories yet.
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Tue, 10 Nov 2026 22:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | bt_hci_le_per_adv_report_common() in subsys/bluetooth/host/scan.c handles the HCI_LE_Periodic_Advertising_Report (and _v2) event. It verified that the fixed event header was present and that the controller-declared Data_Length fits the tailroom of the periodic-sync reassembly buffer, but never checked that the event actually carried as many data bytes as evt->length claims. Both reassembly paths — DATA_STATUS_PARTIAL, and DATA_STATUS_COMPLETE while a chain is already in progress — then called net_buf_simple_add_mem(&per_adv_sync->reassembly, buf->data, evt->length), copying up to 255 bytes starting past the end of the event's real payload. The Data_Length field originates in the HCI controller, so the flaw is reachable in host-only/split builds where the controller is a separate part reached over H4 UART, SPI, USB or an inter-core IPC transport: a malicious, compromised or buggy controller (or an attacker able to inject on that link) can send a report declaring a length larger than the event payload. The generic event dispatcher in subsys/bluetooth/host/hci_core.c only enforces a per-event minimum length and never cross-checks the subevent's internal length field, so nothing else catches it. Builds using Zephyr's own in-image controller are not affected, because the controller always emits a length matching the bytes it appends. Exploitation additionally requires CONFIG_BT_PER_ADV_SYNC with CONFIG_BT_PER_ADV_SYNC_BUF_SIZE > 0 (the option defaults to 0, which compiles the reassembly block out; LE Audio broadcast-sink and Public Broadcast Profile applications that reassemble fragmented periodic advertising data set it), and an established periodic advertising sync. The consequence is an out-of-bounds read of adjacent HCI RX-pool memory — including stale contents of previously received HCI events — which is copied into the reassembly buffer and then delivered to every registered bt_le_per_adv_sync_cb.recv listener as if it were received advertising data, so the disclosed memory becomes application-visible and may be forwarded off-device. The write side remains in bounds because the tailroom check uses the same length value, so there is no memory corruption; impact is limited to information disclosure and undefined behaviour on the over-read. The fix drops any report whose declared length exceeds the remaining event payload, matching the guard already present in the extended and legacy advertising report handlers. | |
| Title | Out-of-bounds read in Bluetooth Host periodic advertising report reassembly due to unvalidated report length | |
| Weaknesses | CWE-125 | |
| References |
| |
| Metrics |
cvssV3_1
|
Projects
Sign in to view the affected projects.
MITRE
Status: PUBLISHED
Assigner: zephyr
Published:
Updated: 2026-11-10T22:07:37.866Z
Reserved: 2026-09-13T19:22:56.728Z
Link: CVE-2026-90832
Vulnrichment
No data.
NVD
Status : Awaiting Analysis
Published: 2026-11-10T22:21:14.167
Modified: 2026-11-10T22:21:14.280
Link: CVE-2026-90832
Redhat
No data.
OpenCVE Enrichment
No data.
Weaknesses