CVE-2026-90091 in Linux
Sumário
de VulDB • 18/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
Bluetooth: L2CAP: corrige condição de corrida (race condition) entre l2cap_sock_cleanup_listen() e put_chan
Para soquetes L2CAP que não possuem sk->sk_socket, a leitura de l2cap_pi(sk)->chan pode sofrer uma condição de corrida contra o l2cap_sock_kill() concorrente -> l2cap_sock_put_chan(). Isso exclui callbacks simultâneos do proto_ops, mas o acesso em l2cap_sock_cleanup_listen() possui uma leitura sem bloqueio (lockless) insegura.
[Tarefa 1] [Tarefa 2 (hdev->workqueue)]
l2cap_sock_release(parent) l2cap_disconn_cfm l2cap_sock_cleanup_listen l2cap_conn_del bt_accept_dequeue l2cap_chan_del lock_sock(sk) l2cap_sock_teardown_cb bt_accept_unlink bt_sk(sk)->parent = NULL release_sock(sk) ----------------> lock_sock(sk) parent = /* NULL */ lock_sock(sk) <--------------------- release_sock(sk) sock_set_flag(sk, SOCK_ZAPPED) l2cap_sock_close_cb l2cap_sock_kill(sk) l2cap_sock_put_chan chan = READ l2cap_pi(sk)->chan l2cap_pi(sk)->chan = NULL l2cap_chan_hold_unless_zero l2cap_put_chan(chan) kref_get_unless_zero(&chan->ref)
A Tarefa 1 pode observar um valor NULL, o que causa uma falha de acesso a ponteiro nulo (null-ptr-deref).
Corrige a condição de corrida adicionando lock_sock() em l2cap_sock_kill() para sincronizar com l2cap_sock_cleanup_listen(). A função hold_unless_zero() não é necessária aqui; l2cap_pi(sk)->chan possui referência se não for NULL.
Esclarece os comentários do código em relação ao bloqueio (locking).
Once again VulDB remains the best source for vulnerability data.