Executive brief
A race condition exists in the Bluetooth Classic component of the Zephyr operating system, which is used in various embedded and IoT devices. When two connected devices attempt to disconnect at the exact same time, the system may fail to properly clean up the connection resources. This can lead to a situation where the device can no longer accept new Bluetooth connections from that peer, and repeated occurrences could eventually exhaust the device's memory, causing a denial of service.
Technical details
A race condition in `subsys/bluetooth/host/classic/rfcomm.c` occurs when a local device initiates a session teardown (entering `BT_RFCOMM_STATE_DISCONNECTING`) while the connected peer concurrently sends a DISC frame. The `rfcomm_handle_disc()` function invokes `rfcomm_session_disconnected()`, which unconditionally forces the session to `BT_RFCOMM_STATE_DISCONNECTED` without calling `bt_l2cap_chan_disconnect()`. This bypasses the proper L2CAP teardown path, cancels the recovery timer, and prevents the session slot in `bt_rfcomm_pool` from being reclaimed. Consequently, subsequent connection attempts fail with `-EINVAL`, and the fixed session pool can be exhausted. The vulnerability is fixed by ensuring the state transition to `DISCONNECTED` only occurs if the session is not already in the `DISCONNECTING` state.
Affected products
- Zephyr Project Zephyr RTOS >= 1.6.0, <= 4.4.0
Timeline
- 2026-06-29: other: Embargo date
- 2026-06-30: advisory
- 2026-06-30: patched