CVE-2026-89583: Linux Kernel Bluetooth Buffer Overflow

CVE-2026-89583 Overview

CVE-2026-89583 is an out-of-bounds read vulnerability in the Linux kernel Bluetooth subsystem. The flaw resides in eir_get_service_data(), which walks Extended Inquiry Response (EIR) advertising data for Service Data fields matching a specific UUID. Incorrect accounting of the remaining buffer length allows the parser to read past the end of hcon->le_per_adv_data[] when processing crafted periodic advertising reports from a remote broadcaster. An attacker in Bluetooth range can leak adjacent kernel memory from struct hci_conn through the BT_ISO_BASE socket option.

Critical Impact
A remote Bluetooth broadcaster can force an Isochronous (ISO) broadcast sink to disclose adjacent kernel memory bytes to user space, enabling information disclosure and potential denial of service.

Affected Products

Linux kernel Bluetooth subsystem (net/bluetooth/eir.c)
Systems configured as ISO broadcast sinks using periodic advertising
Distributions shipping affected stable kernel branches prior to the referenced fix commits

Discovery Timeline

2026-09-11 - CVE-2026-89583 published to NVD
2026-09-14 - Last updated in NVD database

Technical Details for CVE-2026-89583

Vulnerability Analysis

The vulnerability affects eir_get_service_data() in the Linux kernel Bluetooth stack. The function iterates over EIR advertising data searching for a Service Data field with a matching UUID. When a field does not match, the loop advances the pointer by dlen bytes and decrements the tracked buffer length by the same value.

This accounting is incorrect. eir_get_data() reports dlen as the field's data length, but each field actually spans dlen + 2 bytes once the length and type header bytes are counted. When non-Service-Data fields are skipped, additional header bytes are consumed but never subtracted from eir_len. The pointer lands on the next field correctly, while eir_len overstates the remaining buffer.

Root Cause

The root cause is a length-tracking miscalculation [CWE-125]. The two-byte header (length + type) of each skipped EIR field is not deducted from eir_len, so the shortfall compounds across iterations. Eventually the parser reads the length and type bytes of a synthetic "field" located past the end of the buffer.

Attack Vector

For an ISO broadcast sink, the parsed buffer is hcon->le_per_adv_data[], populated from periodic advertising reports emitted by a remote broadcaster. An attacker within Bluetooth radio range can craft a periodic advertising payload packed with mismatching Service Data fields. The walk drifts off the array into adjacent memory of struct hci_conn. If a drifted field matches the Broadcast Audio Announcement (BAA) UUID, those out-of-bounds bytes are stored in iso_pi(sk)->base. User space then retrieves the leaked memory using getsockopt(BT_ISO_BASE).

See the upstream fix in Kernel Git Commit c21fa79, which recomputes eir_len from the end of the buffer on each iteration.

Detection Methods for CVE-2026-89583

Indicators of Compromise

Unexpected Bluetooth periodic advertising reports containing repeated non-matching Service Data fields
Anomalous getsockopt(BT_ISO_BASE) calls returning payloads inconsistent with observed broadcast source data
Kernel warnings, KASAN out-of-bounds read reports, or crashes originating in eir_get_service_data() or eir_get_data()

Detection Strategies

Enable Kernel Address Sanitizer (KASAN) on test kernels to catch OOB reads in Bluetooth EIR parsing paths
Audit process-level use of Bluetooth ISO sockets and correlate BT_ISO_BASE reads with recent periodic advertising activity
Monitor kernel logs for hci_conn related faults on hosts with Bluetooth Low Energy Audio enabled

Monitoring Recommendations

Track kernel package versions on Linux fleet endpoints and flag hosts running unpatched stable branches
Capture Bluetooth HCI traces on high-value hosts operating as broadcast sinks for later forensic review
Alert on unexpected loading or enablement of the Bluetooth bluetooth and hci_* kernel modules on servers where Bluetooth is not required

How to Mitigate CVE-2026-89583

Immediate Actions Required

Apply the upstream kernel fix that recomputes eir_len from the end of the buffer on each parsing iteration
Update to distribution kernel packages that incorporate the referenced stable commits
Disable Bluetooth on systems that do not require it, particularly servers and workstations without a documented Bluetooth Audio use case

Patch Information

The fix is available in the following upstream commits: Kernel Git Commit 1a28aae, Kernel Git Commit 4beb198, Kernel Git Commit 815fc98, Kernel Git Commit b6902ad, Kernel Git Commit bb56e97, and Kernel Git Commit c21fa79. Each stable branch backport recomputes the remaining EIR length from the buffer end on every iteration, eliminating the compounded drift.

Workarounds

Unload the Bluetooth kernel modules where the service is not required: modprobe -r bluetooth
Blocklist Bluetooth modules to prevent automatic load at boot via /etc/modprobe.d/
Restrict physical proximity and RF exposure of high-value systems until patched kernels are deployed

bash

# Configuration example: prevent Bluetooth stack from loading
echo 'install bluetooth /bin/true' | sudo tee /etc/modprobe.d/disable-bluetooth.conf
echo 'blacklist bluetooth'        | sudo tee -a /etc/modprobe.d/disable-bluetooth.conf
echo 'blacklist btusb'            | sudo tee -a /etc/modprobe.d/disable-bluetooth.conf
sudo systemctl disable --now bluetooth.service
sudo update-initramfs -u