CVE-2026-98290: Linux Kernel RFCOMM Race Condition Vulnerability

CVE-2026-98290 Overview

CVE-2026-98290 is a locking-order flaw in the Linux kernel's Bluetooth Radio Frequency Communication (RFCOMM) subsystem. The rfcomm_sock_cleanup_listen() function closes unaccepted child sockets by calling rfcomm_sock_close(), which acquires the child socket lock before rfcomm_dlc_close() takes rfcomm_mutex. The RFCOMM worker takes those same locks in the opposite order, producing a lockdep-reported deadlock condition. An attacker within Bluetooth range can trigger the condition during listener teardown, exhausting kernel locking resources and halting Bluetooth connection handling.

Critical Impact
A reachable deadlock in the RFCOMM listener cleanup path can stall kernel Bluetooth workers, degrading availability on affected Linux systems.

Affected Products

Linux kernel (Bluetooth RFCOMM subsystem)
Distributions shipping vulnerable mainline and stable kernel branches
Any host or embedded device exposing an RFCOMM listening socket over Bluetooth

Discovery Timeline

2026-10-06 - CVE-2026-98290 published to the National Vulnerability Database (NVD)
2026-10-07 - Last updated in NVD database

Technical Details for CVE-2026-98290

Vulnerability Analysis

The defect sits in the RFCOMM socket listener cleanup logic. When a listening RFCOMM socket is torn down, rfcomm_sock_cleanup_listen() iterates children that were never accepted and closes them. The close path takes the child socket lock, then calls into rfcomm_dlc_close(), which acquires rfcomm_mutex.

The RFCOMM worker thread processes incoming connections and Data Link Connection (DLC) state transitions using the reverse order: it holds rfcomm_mutex first, then takes the socket lock. Two threads taking the same pair of locks in opposite orders is the classic AB-BA pattern, and lockdep flags it as a potential deadlock.

The fix closes dequeued child sockets without taking the child socket lock. The accept queue already owns a reference to each child, and bt_accept_dequeue() locks the child while unlinking it and clearing its parent pointer. To prevent a concurrent rfcomm_connect_ind() from enqueuing a new child after cleanup has observed an empty queue, the listening socket is set to BT_CLOSED while its lock is still held. The state check in rfcomm_connect_ind() then rejects additional children once cleanup begins.

Root Cause

The root cause is inverted lock acquisition order between the listener cleanup path and the RFCOMM worker across the per-socket lock and the global rfcomm_mutex. This is a kernel-level race condition and deadlock vulnerability.

Attack Vector

The attack vector is Adjacent Network. An attacker within Bluetooth range can interact with a host that exposes an RFCOMM listening socket, initiating or racing connection indications against listener teardown to trigger the inverted locking sequence. Successful triggering stalls the RFCOMM worker and degrades Bluetooth stack availability. No authentication is required, but attack complexity is high because the race window must be hit precisely.

No public proof-of-concept exploit is listed in the enriched data. See the upstream fixes referenced below for the exact code paths.

Detection Methods for CVE-2026-98290

Indicators of Compromise

Kernel lockdep warnings referencing rfcomm_sock_close, rfcomm_dlc_close, and rfcomm_mutex in dmesg or journal logs.
Hung-task or soft-lockup messages originating from the RFCOMM worker thread.
Bluetooth RFCOMM services becoming unresponsive while the host remains otherwise functional.

Detection Strategies

Monitor kernel ring buffer output for possible circular locking dependency reports naming RFCOMM symbols.
Compare running kernel versions against the fixed commits listed in the upstream references to identify unpatched hosts.
Alert on repeated short-lived RFCOMM connection indications from nearby devices, which may indicate race-condition probing.

Monitoring Recommendations

Centralize dmesg, journald, and /var/log/kern.log collection into a security data lake for anomaly review.
Track Bluetooth daemon (bluetoothd) restarts and RFCOMM socket churn on fleet endpoints.
Correlate Bluetooth adapter state transitions with proximate wireless telemetry where available.

How to Mitigate CVE-2026-98290

Immediate Actions Required

Apply the upstream Linux kernel fixes referenced in the advisory as soon as distribution packages are available.
Disable Bluetooth on systems that do not require it, particularly servers, kiosks, and embedded devices.
Unload the rfcomm kernel module where RFCOMM services are not needed.

Patch Information

The fix is distributed across multiple upstream commits in the stable kernel tree. Review and apply the relevant commits for your branch: Kernel Git Commit 18174b1, Kernel Git Commit 4aafb47, Kernel Git Commit 801fb95, Kernel Git Commit bfce253, Kernel Git Commit c6792c4, Kernel Git Commit c741977, and Kernel Git Commit eb4adaa.

Workarounds

Block loading of the rfcomm module through modprobe blacklist configuration on hosts that do not use serial-port Bluetooth profiles.
Restrict Bluetooth discoverability and pairing to reduce exposure to adjacent attackers.
Where feasible, physically disable or remove the Bluetooth radio on systems in high-risk environments.

bash

# Blacklist the RFCOMM kernel module
echo "blacklist rfcomm" | sudo tee /etc/modprobe.d/blacklist-rfcomm.conf
sudo rmmod rfcomm 2>/dev/null || true

# Verify the module is no longer loaded
lsmod | grep rfcomm