CVE-2026-80819

/// Technical description

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 =

/// Remediation

Check the references section for vendor advisories, patches, and mitigation guidance. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

/// References