Description
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.
Published: 2026-09-04
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability allows an unprivileged local process to read uninitialized bytes from a Bluetooth ISO socket structure. The kernel returns a partially filled sockaddr_iso through getsockname() or getpeername() without clearing all bytes, so the trailing pad byte and, in broadcast cases, several initial bytes of the broadcast structure are leaked. This results in the disclosure of internal kernel memory contents to the caller, providing an information‑exposure vector that could assist further attacks such as memory‑layout inference.

Affected Systems

The affected code is part of the Linux kernel Bluetooth ISO subsystem. All Linux distributions that ship kernel versions prior to the patch referenced in the CVE, regardless of vendor, are potentially impacted. Any system that has BTPROTO_ISO sockets enabled and employs the getsockname()/getpeername() system calls is in the danger zone.

Risk and Exploitability

The CVE does not have a published CVSS score and the EPSS score is not available, indicating that detailed quantitative risk data is missing. The vulnerability is not listed in CISA's KEV catalog. The described attack requires only a local unprivileged user to open a BTPROTO_ISO socket and invoke getsockname(); no network or elevated privileges are needed. Consequently, the attack surface is limited to the local system, but the exposure of kernel memory poses a non‑negligible confidentiality risk to the affected machine.

Generated by OpenCVE AI on September 4, 2026 at 16:43 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version that includes the patch that zeroes the sockaddr structure before returning it. The relevant commit can be found in the kernel sources and is already included in recent kernel releases.
  • Restart the system or reload the kernel to ensure the updated code is active, then restart services that depend on Bluetooth to re‑establish sockets in the new environment.
  • If the system does not require ISO Bluetooth sockets, consider disabling BTPROTO_ISO support via kernel configuration or using firewall rules to block related traffic as a temporary measure.

Generated by OpenCVE AI on September 4, 2026 at 16:43 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 04 Sep 2026 17:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-788

Fri, 04 Sep 2026 15:30:00 +0000

Type Values Removed Values Added
Description 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.
Title Bluetooth: ISO: zero the sockaddr before returning it in getname
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-04T15:12:33.345Z

Reserved: 2026-08-26T14:34:25.791Z

Link: CVE-2026-80761

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-04T16:18:01.190

Modified: 2026-09-04T16:18:01.190

Link: CVE-2026-80761

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-04T16:45:05Z

Weaknesses
  • CWE-788

    Access of Memory Location After End of Buffer