CVE-2026-80761 in Linux
Summary
by MITRE • 09/04/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/04/2026
The Linux kernel contains a memory disclosure vulnerability within its Bluetooth ISO socket implementation, specifically affecting the iso_sock_getname function. This flaw arises from improper initialization of stack-allocated data structures before they are copied to user space. When an application invokes system calls such as getsockname or getpeername, these requests are routed through do_getsockname, which passes a sockaddr_storage structure located on the kernel stack to the driver-specific getname routine. The iso_sock_getname function is responsible for populating this structure with socket address information but fails to clear the memory before writing new data. Consequently, any bytes within the structure that are not explicitly written by the function remain uninitialized and retain their previous values from prior stack usage. This results in a kernel-to-user space leak of sensitive stack memory contents, which may include pointers, cryptographic keys, or other private data used by the operating system during execution.
The vulnerability manifests in two distinct scenarios depending on the socket state and connection type. In the general case involving struct sockaddr_iso, the structure is ten bytes long, yet the function only writes nine bytes comprising the family identifier, Bluetooth device address, and address type. The trailing padding byte remains uninitialized and is subsequently copied to user space during every invocation of getsockname for ISO sockets. This represents a consistent information leak accessible without any prior connection establishment. A more severe variant occurs when dealing with broadcast peer connections, such as those using BIS_LINK or PA_LINK modes. In these cases, the returned length increases by the size of struct sockaddr_iso_bc to accommodate additional broadcast-specific parameters. However, while fields like bc_sid, bc_num_bis, and bc_bis are correctly populated, the first seven bytes corresponding to bc_bdaddr and bc_bdaddr_type are never written. This leaves a significant portion of the structure containing uninitialized stack data exposed to unprivileged processes that have established such connections.
From an operational impact perspective, this vulnerability allows local attackers with low privileges to read kernel memory contents through standard socket API calls. Although the immediate exploitability may be limited by ASLR and other mitigations present in modern Linux distributions, leaking kernel stack data can aid in bypassing security controls or identifying further attack vectors. The issue is classified under CWE-200 as an Information Exposure vulnerability, specifically falling into the category of sensitive information disclosure via uninitialized memory. In terms of offensive security frameworks, this aligns with ATT&CK technique T1083, which covers File and Directory Discovery, although in this context it refers to discovering kernel internal state rather than user files. The flaw highlights a common class of bugs where developers assume stack memory is zeroed or fail to explicitly initialize all fields before exposure.
The resolution involves ensuring that the sockaddr structures are fully initialized before being returned to user space. This can be achieved by applying memset operations to clear the relevant portions of the structure prior to populating it with actual socket address data, a pattern already correctly implemented in other Bluetooth protocols such as L2CAP and RFCOMM within the same codebase. By adopting this consistent approach across all ISO socket handling paths, the kernel prevents the leakage of uninitialized stack bytes. System administrators should apply available kernel updates that include this patch to mitigate the risk of information disclosure. Developers reviewing similar network protocol implementations in the Linux kernel should audit getname functions for proper memory initialization practices to prevent analogous vulnerabilities in other subsystems.