CVE-2026-80761: Linux Kernel Bluetooth ISO Information Leak

CVE-2026-80761 Overview

CVE-2026-80761 is an uninitialized memory disclosure vulnerability in the Linux kernel's Bluetooth ISO (Isochronous) socket implementation. The flaw resides in iso_sock_getname(), which populates a struct sockaddr_iso in place without first zeroing the buffer. As a result, uninitialized bytes from the kernel stack are copied to user space through getsockname(2) and getpeername(2) calls. An unprivileged process can open a BTPROTO_ISO socket and trigger the pad-byte leak with getsockname(). A larger leak involving broadcast peer structures requires an established Broadcast Isochronous Stream (BIS) or Periodic Advertising (PA) connection.

Critical Impact
Local unprivileged users can read small ranges of uninitialized kernel stack memory, potentially exposing sensitive data useful for further exploitation.

Affected Products

Linux kernel Bluetooth subsystem (ISO socket implementation)
Distributions shipping the affected upstream kernel versions prior to the referenced stable commits
Systems with Bluetooth hardware and BTPROTO_ISO socket support enabled

Discovery Timeline

2026-09-04 - CVE-2026-80761 published to NVD
2026-09-04 - Last updated in NVD database

Technical Details for CVE-2026-80761

Vulnerability Analysis

The vulnerability is a classic uninitialized memory use [CWE-908] in kernel socket code. The iso_sock_getname() function fills a struct sockaddr_iso and returns its size without clearing the buffer beforehand. The do_getsockname() path hands getname() an uninitialized sockaddr_storage on the stack, then copies back up to the number of bytes the driver reports. Any byte the driver fails to write is leaked to user space verbatim.

Two distinct leaks exist. First, struct sockaddr_iso is 10 bytes, but only 9 are written (family, iso_bdaddr, and iso_bdaddr_type), exposing a single trailing pad byte on every call. Second, for a broadcast peer (BIS_LINK or PA_LINK), the returned length is extended by sizeof(struct sockaddr_iso_bc), but only bc_sid, bc_num_bis, and bc_bis are populated. The first 7 bytes of that structure, bc_bdaddr and bc_bdaddr_type, are never written.

Root Cause

The root cause is the absence of a memset() call on the destination sockaddr prior to field assignment. Sibling protocol handlers such as L2CAP and RFCOMM already zero their sockaddr buffers in getname for this exact reason. The ISO implementation omitted this defensive step, leaving structure padding and unwritten fields populated with residual kernel stack contents.

Attack Vector

A local unprivileged process opens a BTPROTO_ISO socket and invokes getsockname() to trigger the pad-byte disclosure without additional privileges. The broadcast leak requires establishing a BIS or PA connection, then calling getpeername() on the socket. Each invocation returns a small window of kernel stack memory that may contain pointers, credentials, or other sensitive residue useful for defeating Kernel Address Space Layout Randomization (KASLR) or informing subsequent exploitation stages.

The vulnerability manifests entirely in kernel socket handling. Refer to the upstream fix commits for the exact patched code paths.

Detection Methods for CVE-2026-80761

Indicators of Compromise

Unexpected processes opening AF_BLUETOOTH sockets with the BTPROTO_ISO protocol on systems without a legitimate Bluetooth audio workload.
Repeated getsockname() or getpeername() invocations against ISO sockets from unprivileged user contexts.
Establishment of Broadcast Isochronous Stream (BIS) or Periodic Advertising (PA) connections initiated by non-audio processes.

Detection Strategies

Audit kernel version and Bluetooth subsystem patch level against the referenced stable commits (190b719, 1f6d1f2, 884cf2c, 9069be8).
Enable Linux Audit rules for socket() syscalls filtering on the Bluetooth family and ISO protocol to baseline expected callers.
Correlate telemetry from endpoint protection tooling with anomalous Bluetooth stack activity on servers and workstations that do not require Bluetooth.

Monitoring Recommendations

Forward kernel and audit logs to a centralized analytics platform to identify unusual BTPROTO_ISO usage over time.
Track loaded kernel modules and confirm the Bluetooth stack is only present on hosts that require it.
Alert on unprivileged processes issuing repeated socket introspection syscalls against Bluetooth descriptors.

How to Mitigate CVE-2026-80761

Immediate Actions Required

Apply the upstream Linux kernel patches referenced by commits 190b719, 1f6d1f2, 884cf2c, and 9069be8.
Track distribution vendor advisories and deploy the corresponding kernel updates as they become available.
On systems that do not require Bluetooth, disable or blacklist the Bluetooth kernel modules to eliminate the attack surface.

Patch Information

The fix adds a memset() of the destination sockaddr in iso_sock_getname() before populating fields, matching the behavior already present in L2CAP and RFCOMM getname handlers. This ensures all bytes accounted for in the returned length are initialized, eliminating both the trailing pad-byte leak and the 7-byte broadcast structure leak. Consult the linked kernel git commits for the authoritative source-level change.

Workarounds

Unload the bluetooth kernel module on systems where it is not required: modprobe -r bluetooth.
Blacklist Bluetooth modules in /etc/modprobe.d/ to prevent automatic loading at boot.
Restrict access to Bluetooth functionality through seccomp or Linux Security Module (LSM) policies that block BTPROTO_ISO socket creation for untrusted workloads.

bash

# Prevent the Bluetooth stack from loading on hosts that do not need it
echo 'install bluetooth /bin/true' | sudo tee /etc/modprobe.d/disable-bluetooth.conf
sudo modprobe -r bluetooth