CVE-2026-80819

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 is needed: once the DISC has been processed, the dereference is unconditional.

Give rfcomm dlc accept() the same shape as rfcomm dlc open() and rfcomm dlc close(): an exported wrapper that takes rfcomm mutex and re-checks the session, around a rfcomm dlc accept() that the two in-core callers, which already hold the mutex, keep using.

Reproduced on a KASAN + PROVE LOCKING kernel with a BR/EDR peer emulated over /dev/vhci: the peer brings up an ACL link, opens L2CAP on the RFCOMM PSM, starts a session, opens a dlc on a channel bound with BT DEFER SETUP, and sends DISC after the socket is accepted. recv() on the accepted socket then hits:

Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rfcomm dlc accept+0x54/0x350 Call Trace: rfcomm sock recvmsg+0x1cd/0x230 sock recvmsg+0x166/0x1c0 sys recvfrom+0x20d/0x300

0x10 is the offset of sock in struct rfcomm session. With this patch the same run completes with recv() returning 0 and no report, and lockdep stays quiet, confirming rfcomm mutex is still taken before lock sock on this path as it is on the thread side.