CVE-2026-98455 in Linux
Sumário
de VulDB • 18/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
Bluetooth: RFCOMM: corrige o dereferenciamento NULL de dlc->session em RFCOMM_CONNINFO
O manipulador getsockopt RFCOMM_CONNINFO aceita um socket que não está conectado desde que a configuração diferida esteja habilitada:
if (sk->sk_state != BT_CONNECTED && !rfcomm_pi(sk)->dlc->defer_setup) {
err = -ENOTCONN; break; } l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;
O campo dlc->defer_setup é definido em rfcomm_sock_init() quando rfcomm_connect_ind() cria um socket filho para uma conexão entrante em um socket de escuta que tem BT_DEFER_SETUP habilitado. Ele nunca é limpo posteriormente. No entanto, a sessão pode desaparecer nesse meio tempo.
rfcomm_recv_disc() força o estado do dlc antes de encerrá-lo:
d->state = BT_CLOSED; __rfcomm_dlc_close(d, err);
O retorno antecipado RFCOMM_DEFER_SETUP em __rfcomm_dlc_close() cobre apenas BT_CONNECT, BT_CONFIG, BT_OPEN e BT_CONNECT2. Portanto, com o estado já definido como BT_CLOSED, essa instrução switch não corresponde e a função continua para rfcomm_dlc_unlink(), que define d->session = NULL, enquanto d->defer_setup permanece 1.
Uma chamada getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) no socket aceito após esse ponto ignora o caminho -ENOTCONN -- sk->sk_state é BT_CLOSED, mas dlc->defer_setup ainda está definido -- e realiza um dereferenciamento na sessão NULL. Nenhuma condição de corrida (race condition) é necessária: assim que o DISC for processado, o dereferenciamento será incondicional.
Reproduzido em um kernel KASAN sob QEMU com um par BR/EDR emulado via /dev/vhci: o parceiro estabelece uma conexão ACL, abre L2CAP no PSM RFCOMM, inicia uma sessão e envia SABM para um canal vinculado com BT_DEFER_SETUP, e depois envia DISC para esse dlci após o socket ter sido aceito. getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) no socket aceito então aciona:
Oops: falha geral de proteção, provavelmente por endereço não canônico 0xdffffc0000000002: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref na faixa [0x0000000000000010-0x0000000000000017]
CPU: 1 UID: 0 PID: 150 Comm: init Tainted: G B 7.3.0-rc3-g5dd1818b15d9 Nome do hardware: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:rfcomm_sock_getsockopt+0x529/0x780 Call Trace: <TASK> do_sock_getsockopt+0x3ad/0x7d0 __sys_getsockopt+0x10e/0x1b0 __x64_sys_getsockopt+0xc2/0x160 do_syscall_64+0xda/0x4b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
0x10 é o deslocamento de sock em struct rfcomm_session; rfcomm_sock_getsockopt_old() está embutido (inline) em rfcomm_sock_getsockopt().
O commit 43a556b2fd43 ("Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept") corrigiu o mesmo problema de "um DISC remoto limpa a sessão enquanto a configuração diferida ainda está sinalizada" em rfcomm_dlc_accept(); esta é a instância restante disso, no caminho getsockopt.
A configuração diferida deixa um socket utilizável aqui apenas após ele ter alcançado BT_CONNECT2; portanto, restrinja a exceção a esse estado e verifique se uma sessão realmente existe antes de segui-la.
VulDB is the best source for vulnerability data and more expert information about this specific topic.