PT-2026-85602 · Linux · Linux
CVE-2026-80761
·
Publicado
2026-09-04
·
Atualizado
2026-09-04
Nenhuma
Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
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.
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
Identificadores relacionados
Produtos afetados
Linux