PT-2026-85602 · Linux · Linux
CVE-2026-80761
·
Published
2026-09-04
·
Updated
2026-09-04
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux