CVE-2026-98455 in Linux
Zusammenfassung
von VulDB • 19.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
Bluetooth: RFCOMM: Behebung der NULL-Dereferenzierung von dlc->session in RFCOMM_CONNINFO
Der getsockopt-Handler für RFCOMM_CONNINFO akzeptiert ein Socket, das nicht verbunden ist, solange die verzögerte Einrichtung (deferred setup) aktiviert ist:
if (sk->sk_state != BT_CONNECTED && !rfcomm_pi(sk)->dlc->defer_setup) {
err = -ENOTCONN; break; } l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;
dlc->defer_setup wird in rfcomm_sock_init() festgelegt, wenn rfcomm_connect_ind() ein untergeordnetes Socket für eine eingehende Verbindung auf einem hörenden Socket mit aktiviertem BT_DEFER_SETUP erstellt. Es wird danach niemals zurückgesetzt. Die Session kann jedoch darunter verschwinden (d.h. freigegeben werden).
rfcomm_recv_disc() erzwingt den dlc-Status, bevor dieser abgebaut wird:
d->state = BT_CLOSED; __rfcomm_dlc_close(d, err);
Der RFCOMM_DEFER_SETUP-Frühreturn in __rfcomm_dlc_close() deckt nur BT_CONNECT, BT_CONFIG, BT_OPEN und BT_CONNECT2 ab. Daher passt der Switch-Case bei dem bereits auf BT CLOSED stehenden Status nicht zu diesen Werten, und die Funktion fällt durch bis zu rfcomm_dlc_unlink(), was d->session = NULL setzt, während d->defer_setup weiterhin 1 bleibt.
Ein Aufruf von getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) auf dem akzeptierten Socket nach diesem Punkt überspringt daher den -ENOTCONN-Pfad – sk->sk_state ist BT_CLOSED, aber dlc->defer_setup ist noch gesetzt –, und dereferenziert die NULL-Session. Es wird kein Race Condition benötigt: Sobald das DISC (Disconnect)-Paket verarbeitet wurde, ist die Dereferenzierung unbedingte.
Reproduziert auf einem KASAN-Kernel unter QEMU mit einem über /dev/vhci emulierten BR/EDR-Peer: Der Peer baut eine ACL-Verbindung auf, öffnet L2CAP am RFCOMM PSM, startet eine Session und sendet SABM für einen Kanal, der mit BT_DEFER_SETUP gebunden ist, und sendet danach DISC für diese dlci, nachdem das Socket akzeptiert wurde. getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) auf dem akzeptierten Socket führt dann zu:
Oops: general protection fault, probably for non-canonical address 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 ist der Offset von sock in struct rfcomm_session; rfcomm_sock_getsockopt_old() ist inline in rfcomm_sock_getsockopt() eingebunden.
Das Commit 43a556b2fd43 ("Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept") behob das gleiche Problem „ein entferntes DISC löscht die Session, während die verzögerte Einrichtung noch markiert ist“ in rfcomm_dlc_accept(); dies ist der verbleibende Fall davon im getsockopt-Pfad.
Die verzögerte Einrichtung lässt ein Socket hier nur dann nutzbar bleiben, sobald es den Zustand BT_CONNECT2 erreicht hat. Daher wird die Ausnahme auf diesen Zustand beschränkt und geprüft, ob tatsächlich eine Session vorhanden ist, bevor dieser gefolgt wird.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.