CVE-2026-80683 in Linuxinformação

Sumário

de VulDB • 28/08/2026

No kernel do Linux, a seguinte vulnerabilidade foi resolvida:

Bluetooth: SCO: atribuir ao socket sua própria referência de sco_conn

sco_conn_del() libera uma referência que não possui. Ela obtém uma referência transitiva via sco_conn_hold_unless_zero() e a libera com o sco_conn_put() subsequente ao sco_sock_hold(); o put adicional no ramo !sk libera uma segunda:

conn = sco_conn_hold_unless_zero(conn); ... sk = sco_sock_hold(conn); sco_conn_unlock(conn); sco_conn_put(conn);

if (!sk) {
sco_conn_put(conn); return; }

Quando close() entra em condição de corrida com o Disconnection Complete do controlador, sco_chan_del() limpa conn->sk e libera a referência do socket enquanto sco_conn_del() está sendo executado. sco_conn_del() então vê sk == NULL, seu próprio put reduz a contagem para zero e libera o conn, e o segundo write (put) escreve no kref já liberado:

BUG: KASAN: slab-use-after-free in sco_conn_put.part.0+0x1a/0x190 Write of size 4 at addr ffff8881099dec74 by task kworker/u17:3/413 Workqueue: hci1 hci_rx_work Call Trace: sco_conn_put.part.0+0x1a/0x190 hci_disconn_complete_evt+0x1ee/0x3e0 hci_event_packet+0x54a/0x650 hci_rx_work+0x321/0x3d0 Allocated by task 413: sco_conn_add+0x72/0x1a0 sco_connect_cfm+0x88/0x670 Freed by task 413: sco_conn_del.isra.0+0x3f/0xf0 hci_disconn_complete_evt+0x1ee/0x3e0 refcount_t: underflow; use-after-free.

A causa raiz é que o socket armazena a conexão sem manter uma referência própria. __sco_chan_add() faz:

sco_pi(sk)->conn = conn;

portanto, o socket empresta qualquer referência que seu chamador happens-se-a-ter, e os chamadores cobrem isso com holds (retenções) e puts liberatórios ad-hoc. Atribua ao socket uma referência contada em vez disso: __sco_chan_add() obtém uma e ela é liberada junto com o canal (sco_chan_del()) e em sco_sock_destruct(). Com o socket mantendo sua própria referência, sco_conn_del() não precisa mais do put extra e a retenção redundante em sco_conn_ready() desaparece.

Fazer com que o socket possua sua própria referência significa que a conexão agora é realmente liberada nos caminhos de erro de sco_connect(), onde antes ocorria vazamento (leak), o que por sua vez executa sco_conn_free() e seu hci_conn_drop(conn->hcon). Para manter o balanceamento da contabilidade do hci_conn, torne essa propriedade explícita também: sco_conn_add() consome uma referência de hci_conn e a sco_conn a possui durante toda a sua vida útil. sco_connect() transfere a referência retornada por hci_connect_sco() e não mais a libera nos caminhos de erro; sco_connect_cfm(), que não recebe uma referência, obtém uma com hci_conn_hold() antes de transferi-la para sco_conn_add() (e a libera novamente se a alocação falhar); e o hci_conn_hold() explícito em sco_conn_ready() é removido. Cada referência então tem um único proprietário claro.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Responsável

Linux

Reservar

26/08/2026

Divulgação

28/08/2026

Moderação

aceite

Entrada

VDB-396588

CPE

pronto

EPSS

0.00000

KEV

não

Atividades

muito baixo

Fontes

Interested in the pricing of exploits?

See the underground prices here!