Linux Kernel CVE-2026-89583

Exploitation requires: (1) The target Linux system must have Bluetooth LE support enabled and an ISO broadcast sink socket open (AF_BLUETOOTH, BTPROTO_ISO in broadcast receive mode), which is a specialized LE Audio / Auracast use case not present in default server or desktop configurations; (2) the attacker must be within Bluetooth LE radio range (typically 10-100m) and able to transmit LE periodic advertising (PA) packets - no prior pairing or authentication is required for advertising reception; (3) a local process (or the attacker after initial code execution) must call getsockopt(BT_ISO_BASE) to retrieve the leaked bytes for the information-disclosure impact. The availability impact (potential kernel panic) could occur without local process involvement if the OOB read dereferences a bad value. Standard Bluetooth-enabled desktops not running LE Audio sink applications are not meaningfully exposed, and servers without Bluetooth hardware are entirely unaffected.

CVSS 8.1 (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H) accurately captures the adjacent attack vector but the dual C:H/A:H impact warrants scrutiny. Confidentiality impact H is well-supported: the OOB read leaks struct hci_conn memory bytes into a userspace-readable socket option, which could expose kernel pointers or data from adjacent connection state. Availability impact H reflects that the OOB read accessing arbitrary struct hci_conn fields could also trigger a kernel oops or panic depending on what data is read. The attack requires: (1) the target to have an ISO broadcast sink socket open (LE Audio / Auracast receiver, a specialized Bluetooth use case), (2) the attacker to be within Bluetooth range and able to broadcast LE periodic advertising with crafted Service Data payloads. These constraints substantially limit real-world exposure compared to a generic AV:N flaw. EPSS at 0.17% (6th percentile) is consistent with a kernel Bluetooth path rarely exercised in typical enterprise or server environments. No KEV listing and no public POC exist at time of analysis. The primary real-world risk is on embedded Linux platforms used as LE Audio sink devices (hearing aids, automotive, industrial audio) rather than general-purpose servers.

An attacker with a Bluetooth LE radio within range of a Linux system running an ISO broadcast sink (e.g., an LE Audio receiver application) crafts LE periodic advertising payloads containing a sequence of Service Data fields whose UUIDs do not match the target's BAA UUID, followed by a trailing sequence of bytes that, when the drifted eir_len pointer overshoots the le_per_adv_data buffer, coincidentally match the BAA UUID. The sink copies those out-of-bounds bytes - sourced from adjacent struct hci_conn fields - into iso_pi(sk)->base, which an unprivileged local process then reads via getsockopt(BT_ISO_BASE), obtaining kernel heap data including potential pointer values. No public proof-of-concept exists; exploiting the offset drift to land predictably on a useful field requires knowledge of the exact buffer layout and kernel version.