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.