CVE-2026-80761: Bluetooth: ISO: zero the sockaddr before returning it in getname
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: ISO: zero the sockaddr before returning it in getname
isosockgetname() fills a struct sockaddriso 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 dogetsockname(), which hands getname() an uninitialized sockaddrstorage 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 sockaddriso is 10 bytes but only 9 are written (family, isobdaddr, isobdaddrtype), leaking the trailing pad byte on every call.
- for a broadcast peer (BISLINK or PALINK) the returned length grows by sizeof(struct sockaddrisobc), but only bcsid, bcnumbis and bcbis are filled; bcbdaddr and bcbdaddrtype, the first 7 bytes of that structure, are never written.
An unprivileged process can open a BTPROTOISO 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 Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the kernel fix described in the material: in the Bluetooth ISO path (iso_sock_getname / do_getsockname), zero the returned sockaddr structure (e.g., memset/initialize the sockaddr before copying back to user space) so that any bytes not written are not leaked. This addresses the uninitialized trailing pad byte in struct sockaddr_iso (9 of 10 bytes) and the similar uninitialized fields in sockaddr_storage on the stack.
Linux kernel Bluetooth ISO getname/getsockname/getpeername (BIS_LINK/PA_LINK leak) memset sockaddr structures before returning from getname/getsockname/getpeername = 0 (zero-initialize sockaddr before copying to userspace)
Event History
Frequently Asked Questions
Who can trigger the information leak?
An unprivileged local process that can open a BTPROTO_ISO socket can trigger the one-byte padding leak through getsockname(). Leaking the larger broadcast-specific range requires an established BIS or PA connection.
Which interfaces expose the uninitialized data?
Both getsockname(2) and getpeername(2) reach the affected getname() implementation through do_getsockname(). The ordinary socket-address result leaks a trailing padding byte; broadcast peers can expose additional uninitialized broadcast address fields.
How can I determine whether a system may be affected?
Systems using the Linux kernel Bluetooth ISO (BTPROTO_ISO) socket implementation are in scope. The provided data does not include fixed kernel version numbers, so compare the running kernel's source or applied stable patches with the referenced fixes.