CVE-2026-10654
Received Received - Intake

Race Condition in Zephyr Bluetooth Classic RFCOMM Stack

Publication date: 2026-06-30

Last updated on: 2026-06-30

Assigner: Zephyr Project

Description
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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-06-30
Last Modified
2026-06-30
Generated
2026-06-30
AI Q&A
2026-06-30
EPSS Evaluated
N/A
NVD
CVE-2026-10654
EUVD
EUVD-2026-40369

Affected Vendors & Products

Showing 3 associated CPEs
Vendor Product Version / Range
zephyrproject zephyr to 4.4.0 (exc)
zephyrproject zephyr From 1.6.0 (inc) to 4.4.0 (inc)
zephyrproject zephyr 4.5.0

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-362 The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability is a race condition in the Zephyr Bluetooth Classic RFCOMM host stack. It occurs when both the local device and the connected peer try to disconnect a session at the same time. Specifically, if the local device has started disconnecting and the peer simultaneously sends its own disconnect frame, the local stack mishandles this situation by forcing the session state to DISCONNECTED without properly releasing underlying resources.

As a result, the session becomes permanently stuck because the underlying L2CAP channel is never released and the session slot is never reclaimed. This causes subsequent connection attempts to fail and can eventually exhaust the available session pool.

The issue is due to improper state handling during simultaneous disconnects and was fixed by adding a check to ensure the session only transitions to DISCONNECTED if it is not already in the process of disconnecting.

Impact Analysis

This vulnerability impacts availability and resource management. Specifically, it can cause denial of RFCOMM service for the connected peer because the session becomes permanently wedged and subsequent connection attempts fail.

Repeated exploitation can exhaust the session pool, leading to resource leaks and further denial of service.

There are no memory-safety, confidentiality, or integrity consequences associated with this vulnerability.

Detection Guidance

This vulnerability manifests as a permanently wedged RFCOMM session where the underlying L2CAP channel is never released and the session slot is never reclaimed. Subsequent RFCOMM connection attempts fail with an error (-EINVAL) due to the invalid session state.

Detection would involve monitoring Bluetooth RFCOMM sessions for failures to reconnect or resource exhaustion in the session pool. Specifically, look for repeated connection failures with error codes indicating invalid session states and check if L2CAP channels remain open despite disconnect attempts.

Since the issue is timing-dependent and related to simultaneous disconnect frames, network or system logs capturing Bluetooth RFCOMM disconnect events and errors could help identify occurrences.

No explicit commands are provided in the available resources, but suggested approaches include using Bluetooth debugging tools or commands to inspect active RFCOMM sessions and L2CAP channels, such as:

  • Using `btmon` or similar Bluetooth monitoring tools to capture and analyze RFCOMM disconnect frames and session states.
  • Using system or kernel logs to identify repeated RFCOMM connection failures with error -EINVAL.
  • Inspecting Bluetooth stack internal states if possible, for example via debug interfaces or logs, to check for unreleased L2CAP channels or wedged session slots.
Mitigation Strategies

The primary mitigation is to update the Zephyr Bluetooth Classic RFCOMM host stack to a version that includes the fix for this race condition.

The fix prevents the session from transitioning to the DISCONNECTED state if it is already in the DISCONNECTING state, ensuring proper L2CAP channel teardown and session slot reclamation.

The patch has been merged into the main branch and backported to versions v4.4, v4.3, and v3.7, with the fixed version projected as v4.5.0.

Until the update can be applied, consider minimizing simultaneous disconnect attempts or controlling peer device behavior to reduce the likelihood of the race condition triggering, although this may be difficult due to the timing complexity.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-10654. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart