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.
Published: 2026-06-30
Score: 3.1 Low
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

A race condition in Zephyr's Bluetooth Classic RFCOMM host stack can cause an unclean disconnect when a local device starts tearing down a session while the peer simultaneously sends a DISC frame. The bug forces the RFCOMM session into DISCONNECTED without performing the associated L2CAP teardown, leaving the underlying channel allocated and the session slot in a fixed pool unreclaimed. The result is a permanent resource leak and denial of RFCOMM service for that peer. The flaw triggers only during a high‑complexity timing race and has no memory safety, confidentiality, or integrity impact.

Affected Systems

The vulnerability affects Zephyr project releases up to and including version 4.4.0. Devices running any older Zephyr release that incorporates the OpenBSD RFCOMM stack are susceptible.

Risk and Exploitability

Although the CVSS score is 3.1, indicating low severity, the attack requires simultaneous, remote DISC frames that collide with a local disconnect, a high‑complexity timing exploit. EPSS is unavailable and the flaw is not listed in the CISA KEV catalog. Consequently, exploitation risk is modest but the impact—ongoing denial of RFCOMM service and eventual exhaustion of the session pool—could disrupt availability on compromised devices.

Generated by OpenCVE AI on June 30, 2026 at 17:20 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade Zephyr to a release that includes the RFCOMM teardown fix (any post‑v4.4.0 version).
  • While awaiting an update, limit RFCOMM connections to trusted peers and, if possible, disable remote‑initiated DISC handling to prevent the race condition.
  • Monitor RFCOMM connection attempts and log any -EINVAL errors indicating wedged sessions, and consider resetting L2CAP channels if excess session failures occur.

Generated by OpenCVE AI on June 30, 2026 at 17:20 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Tue, 30 Jun 2026 17:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Tue, 30 Jun 2026 16:45:00 +0000

Type Values Removed Values Added
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.
Title RFCOMM session-disconnect race leaks session/L2CAP and denies further RFCOMM service in Zephyr Bluetooth Classic
Weaknesses CWE-362
References
Metrics cvssV3_1

{'score': 3.1, 'vector': 'CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L'}

Subscriptions

No data.

cve-icon MITRE

Status: PUBLISHED

Assigner: zephyr

Published:

Updated: 2026-06-30T16:43:56.552Z

Reserved: 2026-06-02T15:24:28.191Z

Link: CVE-2026-10654

cve-icon Vulnrichment

Updated: 2026-06-30T16:43:51.482Z

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-06-30T17:30:15Z

Weaknesses
  • CWE-362

    Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')