CVE-2026-98455 — Bluetooth: RFCOMM: fix NULL dereference of dlc->session in RFCOMM_CONNINFO

Affected: Linux

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: RFCOMM: fix NULL dereference of dlc->session in RFCOMM_CONNINFO

The RFCOMM_CONNINFO getsockopt handler accepts a socket that is not connected as long as deferred setup is enabled:

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 is set in rfcomm_sock_init() when rfcomm_connect_ind() creates a child socket for an incoming connection on a listening socket that has BT_DEFER_SETUP enabled. It is never cleared afterwards. The session, however, can go away underneath it.

rfcomm_recv_disc() forces the dlc state before tearing it down:

d->state = BT_CLOSED; __rfcomm_dlc_close(d, err);

The RFCOMM_DEFER_SETUP early return in __rfcomm_dlc_close() only covers BT_CONNECT, BT_CONFIG, BT_OPEN and BT_CONNECT2, so with the state already BT_CLOSED that switch does not match and the function falls through to rfcomm_dlc_unlink(), which sets d->session = NULL, while d->defer_setup stays 1.

A getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) on the accepted socket after that point therefore skips the -ENOTCONN path -- sk->sk_state is BT_CLOSED, but dlc->defer_setup is still set -- and dereferences the NULL session. No race is needed: once the DISC has been processed, the dereference is unconditional.

Reproduced on a KASAN kernel under QEMU with a BR/EDR peer emulated over /dev/vhci: the peer b…

Most recent entries from all

CVE-2026-98455 — Bluetooth: RFCOMM: fix NULL dereference of dlc->session in RFCOMM_CONNINFO