CVE-2026-89583

The Linux kernel's Bluetooth Extended Inquiry Response (EIR) parser contains an out-of-bounds read in eir_get_service_data(), which mis-accounts the remaining buffer length by subtracting only each field's data length instead of its full dlen + 2 footprint, so the length drifts and eventually the parser reads past the end of the buffer. A remote attacker within Bluetooth radio range can trigger this by broadcasting periodic advertising (PA) payloads packed with mismatching Service Data fields to a device acting as an ISO broadcast sink; the parser walks off the le_per_adv_data[] array into the rest of struct hci_conn. If a drifted field matches the BAA UUID, the leaked kernel bytes are copied into the socket's ISO base structure, where user space can read them back via getsockopt(BT_ISO_BASE), yielding disclosure of adjacent kernel heap memory (CVSS 3.1: 8.1, high confidentiality and availability impact, adjacent-network vector). Affected systems are Linux machines whose Bluetooth stack is configured as an LE Audio ISO broadcast sink — a relatively new and specialized role, not the common phone/headset case. No public proof of concept is known, the flaw is not on the CISA KEV list, and no in-the-wild exploitation has been reported.

What to do: Apply kernel updates from your distribution once the fix (recomputing eir_len from the end of the buffer each iteration) is included, and verify with your vendor's advisory that the backported patch covers eir_get_service_data(). If patching is delayed, avoid operating affected systems as ISO broadcast sinks (disable LE Audio broadcast sink / periodic advertising sync where feasible) or turn off Bluetooth entirely on devices that don't need it. Watch kernel logs for slab/KASAN out-of-bounds reports on Bluetooth RX paths as an indicator of probing.