What is the CVSS score of CVE-2026-10654?

CVE-2026-10654 has a CVSS 3.1 base score of 3.1 (Low). CVSS vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L. EPSS exploitation probability: 0.1%.

Is there a patch available for CVE-2026-10654?

Yes, a patch is available for CVE-2026-10654. Update the affected software to the latest version immediately.

Zephyr RTOS CVE-2026-10654

EUVD-2026-40369 LOW

Race Condition (CWE-362)

2026-06-30 zephyr

Race Condition Information Disclosure Zephyr

3.1

CVSS 3.1 · Vendor: zephyr

Severity by source

Vendor (zephyr) PRIMARY

3.1 LOW

AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

vuln.today AI

3.1 LOW

Bluetooth radio adjacency required (AV:A), high-complexity timing race to win (AC:H), impact is availability-only and limited to session slot denial (A:L) with no C or I consequence.

3.1 AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

4.0 AV:A/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

Primary rating from Vendor (zephyr).

CVSS VectorVendor: zephyr

CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

Attack Vector

Adjacent

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

Low

Lifecycle Timeline

Analysis Generated

Jun 30, 2026 - 17:26 vuln.today

DescriptionCVE.org

A race condition in the Zephyr Bluetooth Classic RFCOMM host stack (subsys/bluetooth/host/classic/rfcomm.c) mishandles a simultaneous bidirectional session disconnect. When the local device has initiated a session teardown (state BT_RFCOMM_STATE_DISCONNECTING, DISC sent, RTX timer armed) and the connected peer concurrently sends its own DISC frame for dlci 0, rfcomm_handle_disc() invokes rfcomm_session_disconnected(), which unconditionally forced the session to BT_RFCOMM_STATE_DISCONNECTED without ever calling bt_l2cap_chan_disconnect().

Because the recovery timer was also cancelled and a later UA is ignored in the DISCONNECTED state, the session becomes permanently wedged: the underlying L2CAP channel is never released and the session slot in the fixed bt_rfcomm_pool[CONFIG_BT_MAX_CONN] array is never reclaimed (its conn pointer stays set).

Subsequent bt_rfcomm_dlc_connect() calls on that connection fail with -EINVAL due to the invalid session state, so RFCOMM service is denied for that peer, and repeated occurrences can exhaust the session pool. The DISC frame is peer-controlled over the air, but exploitation requires the peer's DISC to collide with a local-initiated disconnect (a high-complexity timing race). Impact is availability/resource-leak only; there is no memory-safety, confidentiality, or integrity consequence. The defect shipped in released versions (present in v4.4.0 and earlier).

The fix only transitions to DISCONNECTED when the session is not already in DISCONNECTING, preserving the proper L2CAP teardown path.

AnalysisAI

Race condition in Zephyr RTOS Bluetooth Classic RFCOMM host stack (v4.4.0 and earlier) permanently wedges session state and exhausts the fixed bt_rfcomm_pool when a peer-transmitted DISC frame for dlci 0 collides with a simultaneous local-initiated teardown. The underlying L2CAP channel is never released and the session slot is never reclaimed, eventually denying RFCOMM service to the targeted peer across repeated occurrences. No public exploit identified at time of analysis; the CVSS 3.1 score of 3.1 (Low) with AV:A/AC:H accurately reflects both the Bluetooth adjacency prerequisite and the high-complexity timing race required.

Technical ContextAI

The defect resides in subsys/bluetooth/host/classic/rfcomm.c within the Zephyr real-time operating system, an open-source embedded OS maintained by the Linux Foundation and the ZephyrProject consortium. RFCOMM (Radio Frequency Communication) is a Bluetooth Classic protocol that emulates RS-232 serial behavior over L2CAP (Logical Link Control and Adaptation Protocol) channels. The root cause is CWE-362 (Concurrent Execution Using Shared Resource with Improper Synchronization): the RFCOMM session state machine enters BT_RFCOMM_STATE_DISCONNECTING (DISC sent, RTX timer armed) when the local device initiates teardown, but rfcomm_handle_disc() unconditionally invokes rfcomm_session_disconnected() - forcing state to BT_RFCOMM_STATE_DISCONNECTED - without completing the L2CAP channel release via bt_l2cap_chan_disconnect(). The RTX timer is simultaneously cancelled, and later UA frames are silently discarded in the DISCONNECTED state. This leaves the conn pointer populated in the bt_rfcomm_pool[CONFIG_BT_MAX_CONN] fixed array, consuming a session slot indefinitely. Affected products are identified by CPE cpe:2.3:a:zephyrproject:zephyr:*:*:*:*:*:*:*:* through v4.4.0.

RemediationAI

Apply the upstream fix from commit c67b59f891a3a8697f1edb2a0e559fc267e75cc2 in the ZephyrProject repository (https://github.com/zephyrproject-rtos/zephyr/commit/c67b59f891a3a8697f1edb2a0e559fc267e75cc2); the patch conditions the transition to BT_RFCOMM_STATE_DISCONNECTED on the session not already being in DISCONNECTING, preserving the proper L2CAP teardown path. A specific patched tagged release version is not independently confirmed from available data - only a commit reference is provided - so monitor the Zephyr release channel and advisory GHSA-4m37-wp5x-hq4h for an official release build. Where immediate patching is not feasible, disable the Bluetooth Classic RFCOMM profile by setting CONFIG_BT_RFCOMM=n in the Kconfig build configuration; the trade-off is loss of all RFCOMM-dependent Bluetooth Classic services (e.g., Serial Port Profile). Alternatively, restrict Bluetooth adjacency to trusted pre-paired devices and disable Bluetooth discoverable mode, which reduces exposure but does not eliminate the race for already-connected peers.