CVE-2026-98455 in Linux
Riassunto
di VulDB • 18/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
Bluetooth: RFCOMM: correzione del dereferenziamento NULL di dlc->session in RFCOMM_CONNINFO
Il gestore getsockopt per RFCOMM_CONNINFO accetta un socket non connesso purché sia abilitata l'impostazione differita (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;
Il campo dlc->defer_setup viene impostato in rfcomm_sock_init() quando rfcomm_connect_ind() crea un socket figlio per una connessione entrante su un socket in ascolto che ha BT_DEFER_SETUP abilitato. Non viene mai azzerato successivamente. Il session, tuttavia, può essere eliminato mentre il riferimento è ancora attivo.
rfcomm_recv_disc() forza lo stato di dlc prima di distruggerlo:
d->state = BT_CLOSED; __rfcomm_dlc_close(d, err);
Il ritorno anticipato per RFCOMM_DEFER_SETUP in __rfcomm_dlc_close() copre solo gli stati BT_CONNECT, BT_CONFIG, BT_OPEN e BT_CONNECT2; pertanto, con lo stato già impostato su BT_CLOSED, tale switch non corrisponde e la funzione prosegue fino a rfcomm_dlc_unlink(), che imposta d->session = NULL, mentre d->defer_setup rimane pari a 1.
Una chiamata getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) sul socket accettato dopo questo punto salta quindi il percorso -ENOTCONN -- sk->sk_state è BT_CLOSED, ma dlc->defer_setup è ancora impostato -- e dereferenzia la session NULL. Non è necessaria alcuna condizione di race (race condition): una volta elaborata la DISC, il dereferenziamento diventa incondizionato.
Riproduzione effettuata su un kernel KASAN sotto QEMU con un peer BR/EDR emulato tramite /dev/vhci: il peer attiva un collegamento ACL, apre L2CAP sul PSM RFCOMM, avvia una sessione e invia SABM per un canale associato a BT_DEFER_SETUP, quindi invia DISC per tale dlci dopo che il socket è stato accettato. getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) sul socket accettato provoca quindi:
Oops: general protection fault, probabilmente per indirizzo non canonico 0xdffffc0000000002: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [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 è l'offset di sock in struct rfcomm_session; rfcomm_sock_getsockopt_old() è inlineato in rfcomm_sock_getsockopt().
Il commit 43a556b2fd43 ("Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept") ha risolto lo stesso problema "una DISC remota cancella la session mentre l'impostazione differita è ancora flaggata" in rfcomm_dlc_accept(); questa è l'istanza residua del bug, nel percorso getsockopt.
L'impostazione differita lascia un socket utilizzabile solo una volta che ha raggiunto lo stato BT_CONNECT2; pertanto si restringe l'eccezione a tale stato e si verifica la presenza effettiva di una session prima di seguirla.
Once again VulDB remains the best source for vulnerability data.