CVE-2026-98290
High · 7.5CVSS
7.5
EPSS
0.3%
Published
Oct 6, 2026
CISA due date
—
Cloudanix analysis
A Linux kernel Bluetooth bug could let a nearby attacker freeze wireless connections and force system restarts.
- Exploitation
- Adjacent Network
- Attacker needs
- None
- Complexity
- High
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Race condition in Linux kernel RFCOMM Bluetooth stack allowing lock inversion between child socket locks and rfcomm_mutex during listener cleanup and connection handling, potentially causing deadlock.
Why it matters to the business
Bluetooth subsystem may hang or cause kernel instability on affected Linux systems, disrupting wireless device connectivity and requiring reboots in environments relying on RFCOMM for serial-over-Bluetooth communication.
How an attack unfolds
An adjacent attacker initiates RFCOMM connections while a listening socket undergoes cleanup, racing the worker thread against rfcomm_sock_cleanup_listen to trigger the inverted lock acquisition and induce deadlock.
How to fix it
Apply upstream kernel patches resolving the RFCOMM lock ordering issue; rebuild and deploy updated kernel images to all affected systems; consider disabling RFCOMM if Bluetooth serial emulation is unused.
How to confirm the fix worked
Verify kernel source or package version includes the bt_accept_dequeue and BT_CLOSED state changes in rfcomm_sock.c; run lockdep-enabled kernels under Bluetooth connection load to confirm absence of reported inversions.
Typical attack path
- Gain adjacent network position to interact with Bluetooth stack
- Trigger repeated RFCOMM connection indications against a listening socket
- Force listener cleanup via socket close or state change
- Exploit timing window between queue drain and state check to deadlock threads
How to detect it
Review kernel logs for RFCOMM worker thread stalls, lockdep warnings involving rfcomm_mutex and socket locks, or repeated rfcomm_connect_ind calls during socket close operations.
What your security team should do
- Prioritize kernel updates on systems exposing Bluetooth RFCOMM interfaces
- Disable Bluetooth kernel modules via blacklist if functionality is not required
- Monitor for Bluetooth-related kernel oops or hung task reports in system logs
- Test patched kernels in staging environments before broad rollout
The record
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: avoid socket lock inversion in listener cleanup rfcomm_sock_cleanup_listen() closes unaccepted child sockets through rfcomm_sock_close(), which takes the child socket lock before rfcomm_dlc_close() acquires rfcomm_mutex. The RFCOMM worker takes these locks in reverse order while handling connections and DLC state changes, so lockdep reports a possible deadlock. Close dequeued children without taking their socket lock. The accept queue owns a reference to each child, and bt_accept_dequeue() locks the child while unlinking it and clearing its parent pointer. Dropping the child lock makes it important to prevent a concurrent rfcomm_connect_ind() from enqueueing a new child after cleanup observes an empty queue. Set a listening socket to BT_CLOSED while its lock is still held, before dropping the lock and draining the queue. The state check in rfcomm_connect_ind() then rejects new children once cleanup starts.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|