Cloudanix VulnDB

CVE-2026-80761

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's Bluetooth handling could let local programs peek at tiny pieces of hidden system memory.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Data Exposure
Component
OS kernel
Class
Information Disclosure
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

The vulnerability allows an unprivileged process to leak uninitialized kernel stack bytes via getsockname() or getpeername() on BTPROTO_ISO Bluetooth sockets due to incomplete initialization of struct sockaddr_iso and struct sockaddr_iso_bc.

Why it matters to the business

Attackers can obtain small amounts of sensitive kernel memory contents, potentially aiding further exploitation or information gathering on systems using Bluetooth ISO sockets.

How an attack unfolds

An attacker opens a BTPROTO_ISO socket and calls getsockname() to leak a pad byte, or establishes a broadcast connection and calls getpeername() to leak additional bytes from the broadcast sockaddr structure.

How to fix it

Update the Linux kernel to a version that includes the fix for zeroing the sockaddr structure in iso_sock_getname().

How to confirm the fix worked

Verify the kernel source contains the memset call in iso_sock_getname() and test that getsockname() returns fully zeroed structures beyond the written fields.

Typical attack path

  1. Open a BTPROTO_ISO socket
  2. For broadcast leak, establish BIS/PA connection
  3. Call getsockname() or getpeername()
  4. Inspect returned sockaddr for uninitialized bytes

How to detect it

Check for processes calling getsockname or getpeername on ISO sockets; look for unusual Bluetooth socket activity in system logs or audit records.

What your security team should do

  • Apply kernel updates containing the Bluetooth ISO fix
  • Monitor for Bluetooth-related kernel updates
  • Restrict unprivileged access to Bluetooth sockets if possible

The record

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: zero the sockaddr before returning it in getname iso_sock_getname() fills a struct sockaddr_iso in place and returns its size without clearing it first, so bytes it does not write are copied to user space from the kernel stack. The getsockname(2) and getpeername(2) paths both run through do_getsockname(), which hands getname() an uninitialized sockaddr_storage on the stack and copies back up to the number of bytes getname() returns, so the driver has to initialize every byte it accounts for. Two ranges are left uninitialized: - struct sockaddr_iso is 10 bytes but only 9 are written (family, iso_bdaddr, iso_bdaddr_type), leaking the trailing pad byte on every call. - for a broadcast peer (BIS_LINK or PA_LINK) the returned length grows by sizeof(struct sockaddr_iso_bc), but only bc_sid, bc_num_bis and bc_bis are filled; bc_bdaddr and bc_bdaddr_type, the first 7 bytes of that structure, are never written. An unprivileged process can open a BTPROTO_ISO socket and reach the pad leak with getsockname(); the broadcast leak needs an established BIS/PA connection. l2cap and rfcomm already memset their sockaddr in getname for the same reason; do the same here.

Affected packages

Ecosystem Package Introduced Fixed