CVE-2026-80819 in Linux
Summary
by MITRE • 09/04/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/04/2026
The Linux kernel contains a critical race condition vulnerability within the Bluetooth RFCOMM subsystem that leads to a null pointer dereference when handling deferred socket setup operations under specific teardown conditions. This flaw resides in the rfcomm_sock_recvmsg function, which is responsible for completing a deferred connection establishment by invoking rfcomm_dlc_accept without acquiring the necessary rfcomm_mutex lock. The vulnerability arises because this specific code path diverges from all other entry points into RFCOMM data link connection management functions, such as rfcomm_dlc_open and rfcomm_dlc_close, which properly serialize access to shared session structures using mutex locks. By omitting this synchronization primitive, the kernel exposes a window where internal state can be modified concurrently by another thread or process, leading to memory corruption and system instability.
The technical mechanism of exploitation involves a specific sequence of events involving deferred setup flags and remote disconnection commands. When an RFCOMM data link connection is opened with the BT_DEFER_SETUP flag, the actual acceptance logic is delayed until recvmsg is called on the socket. During this delay, if a remote peer sends a DISC (Discard) command to terminate the session, the kernel processes this by setting the DLC state to BT_CLOSED and calling __rfcomm_dlc_close. Although there exists a check for the RFCOMM_DEFER_SETUP bit intended to serialize acceptance against teardown, it only applies when the connection is in active states like BT_CONNECT or BT_CONFIG. Once the remote DISC command forces the state to BT_CLOSED, this serialization logic fails to trigger. Consequently, __rfcomm_dlc_close proceeds to unlink the DLC and explicitly sets d->session to NULL.
Subsequently, when an application thread calls recvmsg on the socket to complete the deferred setup, it executes rfcomm_dlc_accept without holding any locks. This function immediately attempts to dereference d->session to access the underlying sock structure. Since a previous remote DISC command has already nullified this pointer, the kernel performs an invalid memory access at offset 0x10 within struct rfcomm_session, which corresponds to the sock member. This results in a general protection fault and a KASAN-reported null-pointer dereference crash. The vulnerability is particularly severe because it does not require complex timing windows; once the remote DISC packet is processed by the kernel before the local application performs the recv call, the condition for the crash is unconditionally met upon that specific system call invocation.
From a security classification perspective, this issue aligns with CWE-416 Use After Free and CWE-824 Access of Uninitialized Pointer, as it involves accessing memory through a pointer that has been invalidated by concurrent state changes. In terms of the MITRE ATT&CK framework for Linux systems, this vulnerability facilitates Denial of Service via resource exhaustion or system crash, potentially impacting availability in environments where Bluetooth services are exposed to untrusted peers over virtual interfaces like /dev/vhci. The lack of proper locking also represents a violation of fundamental concurrency control principles outlined in CWE-362 Race Condition, highlighting the importance of consistent lock acquisition across all code paths that modify shared kernel data structures.
The resolution involves restructuring rfcomm_dlc_accept to mirror the safety patterns used by other RFCOMM functions. The fix introduces an exported wrapper function that acquires the rfcomm_mutex before proceeding with any operations on the session object. This ensures mutual exclusion between the deferred accept path and teardown paths such as __rfcomm_dlc_close or rfcomm_process_sessions. Inside this locked context, the code re-checks the validity of the session pointer to prevent use-after-free scenarios even if a race condition occurred during lock acquisition. The original logic is moved into an internal helper function that assumes the mutex is already held by callers who manage their own locking contexts. This approach guarantees thread safety and prevents null dereferences regardless of the order in which remote disconnection commands and local accept operations are processed.
Mitigation strategies for organizations running affected Linux kernels include immediate patching to the latest stable release where this fix has been integrated. For systems that cannot be patched immediately, administrators should consider restricting Bluetooth service exposure by disabling RFCOMM support if it is not strictly required, or implementing network-level filtering to prevent untrusted devices from initiating connections on vulnerable channels. Additionally, enabling kernel hardening features such as KASAN and PROVE_LOCKING in development environments can help detect similar concurrency issues early in the software lifecycle before they reach production deployments. Regular auditing of Bluetooth stack configurations against known vulnerability databases is also recommended to maintain a robust security posture for wireless communication subsystems.