CVE-2026-80819 — Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept

Affected: Linux

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

Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept

rfcomm_sock_recvmsg() completes a deferred setup by calling rfcomm_dlc_accept() without holding any RFCOMM lock:

if (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) { rfcomm_dlc_accept(d); return 0; }

and rfcomm_dlc_accept() dereferences the session on its first line:

struct sock *sk = d->session->sock->sk;

Every other path that touches d->session runs under rfcomm_mutex: rfcomm_dlc_open(), rfcomm_dlc_close(), rfcomm_dlc_exists(), rfcomm_dlc_send_rpn(), and the RFCOMM thread through rfcomm_process_sessions(). rfcomm_connect_ind() is even documented as "called under rfcomm_lock()". This call site is the only one that skips it.

The RFCOMM_DEFER_SETUP bit looks like it serialises the accept against teardown, since __rfcomm_dlc_close() returns early when it wins the test_and_clear. But rfcomm_recv_disc() forces the state first:

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

and the early return only covers BT_CONNECT, BT_CONFIG, BT_OPEN and BT_CONNECT2. With the state already BT_CLOSED that switch does not match, the bit is never consulted, and __rfcomm_dlc_close() falls through to rfcomm_dlc_unlink(), which sets d->session = NULL.

So a remote DISC on a deferred dlc clears the session while leaving RFCOMM_DEFER_SETUP set. The next recvmsg() then passes the test_and_clear and dereferences a NULL session. No timing window i…

Most recent entries from all

CVE-2026-80819 — Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept