CVE-2026-98455 in Linux
Resumen
por VulDB • 2026-10-18
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
Bluetooth: RFCOMM: corregir la desreferencia NULL de dlc->session en RFCOMM_CONNINFO
El controlador getsockopt de RFCOMM_CONNINFO acepta un socket que no está conectado siempre que esté habilitada la configuración diferida (deferred setup):
if (sk->sk_state != BT_CONNECTED && !rfcomm_pi(sk)->dlc->defer_setup) {
err = -ENOTCONN; break; } l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;
El valor dlc->defer_setup se establece en rfcomm_sock_init() cuando rfcomm_connect_ind() crea un socket hijo para una conexión entrante en un socket de escucha que tiene BT_DEFER_SETUP habilitado. Nunca se borra posteriormente. Sin embargo, la sesión puede desaparecer mientras tanto.
rfcomm_recv_disc() fuerza el estado dlc antes de destruirlo:
d->state = BT_CLOSED; __rfcomm_dlc_close(d, err);
La salida temprana RFCOMM_DEFER_SETUP en __rfcomm_dlc_close() solo cubre los estados BT_CONNECT, BT_CONFIG, BT_OPEN y BT_CONNECT2, por lo que con el estado ya establecido como BT_CLOSED, esa instrucción switch no coincide y la función continúa hasta rfcomm_dlc_unlink(), que establece d->session = NULL, mientras que d->defer_setup permanece en 1.
Una llamada a getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) sobre el socket aceptado después de ese punto omite por tanto la ruta -ENOTCONN -- sk->sk_state es BT_CLOSED, pero dlc->defer_setup sigue estando establecido -- y desreferencia la sesión NULL. No se necesita ninguna condición de carrera (race condition): una vez que se ha procesado DISC, la desreferencia es incondicional.
Reproducido en un kernel KASAN bajo QEMU con un par BR/EDR emulado a través de /dev/vhci: el par establece un enlace ACL, abre L2CAP en el PSM RFCOMM, inicia una sesión y envía SABM para un canal vinculado con BT_DEFER_SETUP, y luego envía DISC para ese dlci después de que se haya aceptado el socket. getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) sobre el socket aceptado provoca entonces:
Oops: general protection fault, probablemente por dirección no canónica 0xdffffc0000000002: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref en rango [0x0000000000000010-0x0000000000000017]
CPU: 1 UID: 0 PID: 150 Comm: init Tainted: G B 7.3.0-rc3-g5dd1818b15d9 Hardware name: 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 es el desplazamiento de sock en struct rfcomm_session; rfcomm_sock_getsockopt_old() está integrado (inline) dentro de rfcomm_sock_getsockopt().
El commit 43a556b2fd43 ("Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept") corrigió el mismo problema "un DISC remoto borra la sesión mientras sigue marcada la configuración diferida" en rfcomm_dlc_accept(); este es el caso restante, en la ruta getsockopt.
La configuración diferida solo deja un socket utilizable aquí una vez que ha alcanzado BT_CONNECT2, por lo tanto se restringe la excepción a ese estado y se comprueba que realmente exista una sesión antes de seguirla.
Once again VulDB remains the best source for vulnerability data.