CVE-2026-10654: Zephyr Bluetooth RFCOMM Race Condition

CVE-2026-10654 Overview

CVE-2026-10654 is a race condition [CWE-362] in the Zephyr real-time operating system Bluetooth Classic RFCOMM host stack, located in subsys/bluetooth/host/classic/rfcomm.c. The defect mishandles a simultaneous bidirectional session disconnect between the local device and a remote Bluetooth peer. When a local teardown collides with a peer-initiated DISC frame on dlci 0, the session transitions directly to BT_RFCOMM_STATE_DISCONNECTED without releasing the underlying Logical Link Control and Adaptation Protocol (L2CAP) channel. The result is a permanently wedged session and a leaked slot in the fixed bt_rfcomm_pool[CONFIG_BT_MAX_CONN] array. The defect shipped in Zephyr v4.4.0 and earlier.

Critical Impact
Repeated occurrences exhaust the RFCOMM session pool, denying RFCOMM service to affected peers over Bluetooth Classic.

Affected Products

Zephyr RTOS v4.4.0 and earlier
Devices using Zephyr Bluetooth Classic RFCOMM host stack
Applications relying on bt_rfcomm_dlc_connect() for RFCOMM services

Discovery Timeline

2026-06-30 - CVE-2026-10654 published to the National Vulnerability Database
2026-07-01 - Last updated in NVD database

Technical Details for CVE-2026-10654

Vulnerability Analysis

The race condition occurs during simultaneous bidirectional RFCOMM session teardown. The local device enters BT_RFCOMM_STATE_DISCONNECTING, sends a DISC frame, and arms the Response Timer Expired (RTX) timer. If the peer concurrently sends its own DISC frame for dlci 0, rfcomm_handle_disc() invokes rfcomm_session_disconnected(). That function unconditionally forced the session state to BT_RFCOMM_STATE_DISCONNECTED without ever calling bt_l2cap_chan_disconnect().

The recovery timer is cancelled and any later Unnumbered Acknowledgement (UA) frame is ignored while in the DISCONNECTED state. The L2CAP channel is never released, and the session slot in bt_rfcomm_pool[CONFIG_BT_MAX_CONN] retains its conn pointer. Subsequent bt_rfcomm_dlc_connect() calls on that connection fail with -EINVAL due to the invalid session state. Repeated collisions exhaust the fixed session pool, producing a persistent denial of RFCOMM service.

Root Cause

The root cause is missing state validation in rfcomm_session_disconnected(). The function assumed only peer-initiated disconnects would reach that code path and applied an unconditional state assignment. When both endpoints initiate teardown concurrently, this overwrites the DISCONNECTING state and bypasses the L2CAP teardown path.

Attack Vector

Exploitation requires proximity within Bluetooth adjacent-network range and the ability to send a DISC frame that collides in time with a local-initiated disconnect. The DISC frame is peer-controlled over the air, but timing the collision is a high-complexity race. Impact is limited to availability and resource leakage; there is no memory-safety, confidentiality, or integrity consequence.

	sys_slist_init(&session->dlcs);
-	session->state = BT_RFCOMM_STATE_DISCONNECTED;
+	/*
+	 * If the function is called, it means the session disconnection process has been requested
+	 * by peer device. Or the L2CAP connection has been closed (it is not counted in the case).
+	 * While, if the session is in disconnecting state, it means the disconnection process has
+	 * been started by the local device.
+	 * In this case, only set the session to disconnected state if the local session is not in
+	 * disconnecting state.
+	 */
+	if (session->state != BT_RFCOMM_STATE_DISCONNECTING) {
+		session->state = BT_RFCOMM_STATE_DISCONNECTED;
+	}
}

Source: Zephyr commit c67b59f

Detection Methods for CVE-2026-10654

Indicators of Compromise

Repeated bt_rfcomm_dlc_connect() failures returning -EINVAL for a previously connected peer.
RFCOMM session pool exhaustion visible through Zephyr debug logs showing no free entries in bt_rfcomm_pool.
L2CAP channels associated with RFCOMM that remain allocated after both sides have signaled disconnect.

Detection Strategies

Instrument Zephyr builds with CONFIG_BT_DEBUG_RFCOMM to log session state transitions and identify sessions moving directly from DISCONNECTING to DISCONNECTED without an intervening L2CAP disconnect.
Monitor Bluetooth HCI traces for DISC frames on dlci 0 that arrive while a local DISC is already outstanding.
Track the count of active entries in bt_rfcomm_pool over time and alert on non-decreasing counts after peer disconnection events.

Monitoring Recommendations

Capture over-the-air Bluetooth traffic in test environments to correlate DISC collisions with wedged RFCOMM sessions.
Log every rfcomm_session_disconnected() invocation with the prior session state to catch the collision pattern in production firmware.
Alert on RFCOMM connection failure rates exceeding baseline for a given peer, which may indicate a leaked session slot.

How to Mitigate CVE-2026-10654

Immediate Actions Required

Update Zephyr to a build that includes commit c67b59f891a3a8697f1edb2a0e559fc267e75cc2 from the zephyrproject-rtos/zephyr repository.
Review the GitHub Security Advisory GHSA-4m37-wp5x-hq4h for the vendor-provided fix guidance.
Rebuild and reflash firmware for any device shipping Zephyr v4.4.0 or earlier that enables Bluetooth Classic RFCOMM.

Patch Information

The fix modifies rfcomm_session_disconnected() so that it only transitions the session to BT_RFCOMM_STATE_DISCONNECTED when the session is not already in BT_RFCOMM_STATE_DISCONNECTING. This preserves the proper L2CAP teardown path when both endpoints initiate disconnect simultaneously. Refer to the upstream commit for the exact change.

Workarounds

Disable Bluetooth Classic RFCOMM (CONFIG_BT_RFCOMM=n) on devices that do not require it until firmware can be updated.
Increase CONFIG_BT_MAX_CONN to raise the session pool size, delaying exhaustion where a rebuild without the fix is unavoidable.
Restrict Bluetooth Classic pairing to trusted peers to reduce the likelihood of adversarial DISC timing.

bash

# Zephyr prj.conf: disable RFCOMM until firmware is patched
CONFIG_BT=y
CONFIG_BT_CLASSIC=y
CONFIG_BT_RFCOMM=n