CVE-2026-10654: Zephyr Bluetooth RFCOMM Race Condition Causes Session Pool Exhaustion

Technical summary

The vulnerability exists in Zephyr's RFCOMM host stack (subsys/bluetooth/host/classic/rfcomm.c) where rfcomm_handle_disc() fails to handle the case of simultaneous bidirectional disconnect correctly. When a local device has already initiated teardown (state BT_RFCOMM_STATE_DISCONNECTING with RTX timer active) and a peer sends its own DISC frame for DLCI 0, the session transitions to BT_RFCOMM_STATE_DISCONNECTED without invoking bt_l2cap_chan_disconnect(). This leaves the underlying L2CAP channel open and the session descriptor in the fixed-size bt_rfcomm_pool array permanently marked as in-use. Subsequent UA frames are ignored in the DISCONNECTED state, preventing normal recovery. The session slot is never reclaimed (its conn pointer remains set), and future bt_rfcomm_dlc_connect() calls fail with -EINVAL, denying RFCOMM service for that peer until restart.

Business impact

For devices running Zephyr's Bluetooth stack, this creates a subtle availability risk. Repeatedly triggering the race condition—though difficult—could exhaust RFCOMM session slots, temporarily denying Bluetooth Classic connectivity to additional peers. In embedded IoT or industrial control scenarios where Bluetooth is relied upon for critical operations or where devices maintain many concurrent connections, accumulated session exhaustion could force a reboot. The high timing complexity means this is unlikely to be triggered by accident, but a determined attacker with proximity could exploit it during normal disconnection cycles to degrade service.

Affected systems

Zephyr Project versions 4.4.0 and earlier are affected. The vulnerability exists in the Bluetooth Classic RFCOMM subsystem, so only devices that enable BT_RFCOMM configuration and use RFCOMM (Serial Port Profile, or SPP) are susceptible. Verify your Zephyr version and check your device tree or menuconfig for CONFIG_BT_RFCOMM enablement.

Exploitability

Exploitation requires precise timing: a peer must send a DISC frame during the narrow window when the local device has initiated its own disconnect and armed the RTX recovery timer, but before the expected UA response arrives. This collision is complex to orchestrate reliably. However, an attacker with Bluetooth proximity and knowledge of the victim device's RFCOMM connection lifecycle could repeatedly attempt to create this collision and gradually degrade session availability. The DISC frame is entirely peer-controlled and sent over the air, placing the attack surface within wireless range.

Remediation

Update to a patched version of Zephyr that includes the fix for CVE-2026-10654. The remedy modifies rfcomm_handle_disc() to only transition to DISCONNECTED when the session is not already in DISCONNECTING state, ensuring the L2CAP teardown path completes correctly and the session slot is properly reclaimed. Verify the patch version against the official Zephyr advisory before deploying.

Patch guidance

Apply the security patch to your Zephyr source tree or upgrade to a release version that includes the fix. If you are building Zephyr from source, inspect subsys/bluetooth/host/classic/rfcomm.c and confirm that rfcomm_handle_disc() includes a state check before forcing the transition to DISCONNECTED. Recompile your firmware and re-flash all affected devices. In environments where immediate patching is infeasible, consider disabling CONFIG_BT_RFCOMM if RFCOMM services are not essential to your application.

Detection guidance

Monitor for repeated RFCOMM connection failures with -EINVAL error codes originating from the same peer, especially if they correlate with recent disconnections. Enable Zephyr's Bluetooth subsystem logging at DEBUG level to observe state transitions in rfcomm_handle_disc() and confirm whether sessions are transitioning to DISCONNECTED without proper L2CAP teardown. Inspect the runtime state of bt_rfcomm_pool entries; a session with a non-null conn pointer in DISCONNECTED state is suspicious. In production, track RFCOMM session slot availability over time; a declining pool may indicate accumulation of wedged sessions.

Why prioritize this

Although the CVSS score is low (3.1), this vulnerability warrants timely attention because it enables resource exhaustion in a relatively deterministic manner once the race condition is understood. For devices relying on RFCOMM for continuous or critical Bluetooth functionality—such as IoT sensors, wearables, or industrial controllers—session pool exhaustion could be a stepping stone to availability attacks. The fix is straightforward and low-risk, making patching a sensible hygiene measure for any Zephyr deployment using Bluetooth Classic.

Risk score, explained

CVSS 3.1 (LOW) reflects the constraints on exploitability: the attack vector is Adjacent (Bluetooth proximity only), the attack complexity is High (precise timing required), and the impact is limited to Availability with no Confidentiality or Integrity loss. However, the score does not capture the potential for repeated exploitation or the context-dependent severity in mission-critical Bluetooth environments. Organizations should layer this with their own risk assessment, factoring in device deployment, connectivity reliance, and attacker proximity likelihood.

Frequently asked questions