Description
In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: RFCOMM: connect the session socket without rfcomm_mutex

An RFCOMM connect() issued while a BR/EDR link is being authenticated
makes lockdep report a circular dependency, and the reported cycle is a
real AB/BA between rfcomm_mutex and hdev->lock.

rfcomm_security_cfm() is called from the HCI event path, which already
holds hdev->lock:

hci_rx_work()
hci_event_packet()
hci_cc_read_enc_key_size() [hdev->lock]
hci_encrypt_cfm() [hci_cb_list_lock]
rfcomm_security_cfm() [rfcomm_mutex]

while an RFCOMM connect() from userspace takes the same two locks the
other way round:

rfcomm_sock_connect()
rfcomm_dlc_open() [rfcomm_mutex]
__rfcomm_dlc_open()
rfcomm_session_create()
kernel_connect()
l2cap_sock_connect()
l2cap_chan_connect() [hdev->lock]

WARNING: possible circular locking dependency detected
kworker/u131:1/1128 is trying to acquire lock:
rfcomm_mutex, at: rfcomm_security_cfm+0x31/0x3e0 [rfcomm]
but task is already holding lock:
hci_cb_list_lock, at: hci_cc_read_enc_key_size+0x1d2/0xcc0
Chain exists of:
rfcomm_mutex --> &hdev->lock --> hci_cb_list_lock

hci_auth_complete_evt() and hci_encrypt_change_evt() reach the callback
the same way.

Both orders have to be seen in the same boot, which is why a BR/EDR
connection alone is not enough to show it: a session set up by the
remote side is created by rfcomm_accept_connection() in krfcommd, which
calls kernel_accept() and never takes hdev->lock under rfcomm_mutex.
Connecting a device that authenticates and encrypts the link and then
calling connect() on an RFCOMM socket towards any address - the connect
does not have to succeed, the order is recorded before the page timeout
- reports it every time.

Only the session socket has to be connected with the lock held, and it
does not: nothing else can see the socket before it is put on the
session list. So connect it first and take rfcomm_mutex afterwards,
which removes the rfcomm_mutex -> hdev->lock order for good, rather
than keeping the HCI event path out of rfcomm_mutex.

rfcomm_session_create() becomes rfcomm_session_connect(), which returns
the connected socket without touching the session list, and
rfcomm_dlc_open() adds the session once it holds the lock again. If
another opener added a session for the same pair while this socket was
connecting, that session is used and this socket is dropped.
__rfcomm_dlc_open() now takes the session it should use, and its state
check runs after the lock is re-acquired, so a DLC that was opened or
closed in the meantime is still handled.

Over an existing ACL link the connection can complete before the
session reaches the list, and the wakeup from the socket callback is
then lost, so krfcommd is woken once the session is visible.

Connecting without the lock opens a window in which the socket can be
closed. The DLC is not on a session yet, so rfcomm_dlc_close() finds
nothing to do and returns without touching it, and rfcomm_dlc_open()
would then attach a DLC whose owner is gone. rfcomm_dlc_close() now
marks such a DLC with RFCOMM_CLOSED, and rfcomm_dlc_open() checks the
mark once it holds rfcomm_mutex again and drops the socket instead of
attaching the DLC. The mark is cleared when an open starts, so a DLC
that is reused is not affected. This covers both callers of
rfcomm_dlc_open(), the socket and the tty layer.
Published: 2026-10-23
Score: 4.7 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service
Action: Patch
AI Analysis

Impact

The vulnerability is a lock ordering issue in the Linux kernel's Bluetooth RFCOMM subsystem. An RFCOMM connect() made while a BR/EDR link is undergoing authentication triggers lockdep to report a circular dependency between rfcomm_mutex and hdev->lock. This inversion can lead to a deadlock or other locking stalls, potentially causing the Bluetooth stack to freeze or fail to establish connections. No code execution or privilege escalation path is disclosed, so the primary impact is a denial of service to Bluetooth operations.

Affected Systems

The flaw affects the Linux kernel on any system that implements RFCOMM in the Bluetooth stack. The input lists only "Linux:Linux" as the affected vendor and product, and no specific kernel version is given. The patch resolving the issue is included in later kernel releases following the commits referenced in the description, so any system running a kernel prior to those revisions is potentially susceptible.

Risk and Exploitability

The CVSS score is 4.7, indicating a low to moderate severity. The EPSS score is below 1%, meaning exploitation is unlikely at present. The flaw is not in CISA's KEV catalog, and no public exploitation has been recorded. Based on the description, it is inferred that attack vectors require an application to initiate an RFCOMM connection while a BR/EDR link is authenticating; this could be triggered by a local program with Bluetooth access. Because the vulnerability leads to a circular lock dependency that can cause a deadlock and a denial of service to Bluetooth functions, the risk is moderate but the likelihood of exploitation remains low.

Generated by OpenCVE AI on October 29, 2026 at 19:12 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version that includes the rfcomm_session_connect fix (any release after the commits cited).
  • Restart the Bluetooth daemon (bluetoothd) after updating the kernel or applying the patch to ensure the new lock ordering is active.
  • Verify that lockdep no longer reports the circular dependency in dmesg or system logs; if the warning persists, investigate further or delay connecting RFCOMM services until the fix is applied.

Generated by OpenCVE AI on October 29, 2026 at 19:12 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Ubuntu USN Ubuntu USN USN-9018-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9018-2 Linux kernel (HWE) vulnerabilities
Ubuntu USN Ubuntu USN USN-9019-1 Linux kernel (Azure) vulnerabilities
History

Fri, 30 Oct 2026 13:00:00 +0000

Type Values Removed Values Added
References

Thu, 29 Oct 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-833
References
Metrics threat_severity

None

 cvssV3_1

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

threat_severity

Moderate

Sat, 24 Oct 2026 03:30:00 +0000

Type Values Removed Values Added
First Time appeared Linux linux
Vendors & Products Linux linux

Fri, 23 Oct 2026 15:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362

Fri, 23 Oct 2026 12:45:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: connect the session socket without rfcomm_mutex An RFCOMM connect() issued while a BR/EDR link is being authenticated makes lockdep report a circular dependency, and the reported cycle is a real AB/BA between rfcomm_mutex and hdev->lock. rfcomm_security_cfm() is called from the HCI event path, which already holds hdev->lock: hci_rx_work() hci_event_packet() hci_cc_read_enc_key_size() [hdev->lock] hci_encrypt_cfm() [hci_cb_list_lock] rfcomm_security_cfm() [rfcomm_mutex] while an RFCOMM connect() from userspace takes the same two locks the other way round: rfcomm_sock_connect() rfcomm_dlc_open() [rfcomm_mutex] __rfcomm_dlc_open() rfcomm_session_create() kernel_connect() l2cap_sock_connect() l2cap_chan_connect() [hdev->lock] WARNING: possible circular locking dependency detected kworker/u131:1/1128 is trying to acquire lock: rfcomm_mutex, at: rfcomm_security_cfm+0x31/0x3e0 [rfcomm] but task is already holding lock: hci_cb_list_lock, at: hci_cc_read_enc_key_size+0x1d2/0xcc0 Chain exists of: rfcomm_mutex --> &hdev->lock --> hci_cb_list_lock hci_auth_complete_evt() and hci_encrypt_change_evt() reach the callback the same way. Both orders have to be seen in the same boot, which is why a BR/EDR connection alone is not enough to show it: a session set up by the remote side is created by rfcomm_accept_connection() in krfcommd, which calls kernel_accept() and never takes hdev->lock under rfcomm_mutex. Connecting a device that authenticates and encrypts the link and then calling connect() on an RFCOMM socket towards any address - the connect does not have to succeed, the order is recorded before the page timeout - reports it every time. Only the session socket has to be connected with the lock held, and it does not: nothing else can see the socket before it is put on the session list. So connect it first and take rfcomm_mutex afterwards, which removes the rfcomm_mutex -> hdev->lock order for good, rather than keeping the HCI event path out of rfcomm_mutex. rfcomm_session_create() becomes rfcomm_session_connect(), which returns the connected socket without touching the session list, and rfcomm_dlc_open() adds the session once it holds the lock again. If another opener added a session for the same pair while this socket was connecting, that session is used and this socket is dropped. __rfcomm_dlc_open() now takes the session it should use, and its state check runs after the lock is re-acquired, so a DLC that was opened or closed in the meantime is still handled. Over an existing ACL link the connection can complete before the session reaches the list, and the wakeup from the socket callback is then lost, so krfcommd is woken once the session is visible. Connecting without the lock opens a window in which the socket can be closed. The DLC is not on a session yet, so rfcomm_dlc_close() finds nothing to do and returns without touching it, and rfcomm_dlc_open() would then attach a DLC whose owner is gone. rfcomm_dlc_close() now marks such a DLC with RFCOMM_CLOSED, and rfcomm_dlc_open() checks the mark once it holds rfcomm_mutex again and drops the socket instead of attaching the DLC. The mark is cleared when an open starts, so a DLC that is reused is not affected. This covers both callers of rfcomm_dlc_open(), the socket and the tty layer.
Title Bluetooth: RFCOMM: connect the session socket without rfcomm_mutex
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-30T12:40:54.430Z

Reserved: 2026-09-25T10:25:14.385Z

Link: CVE-2026-99009

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-23T13:17:23.470

Modified: 2026-10-30T13:21:35.640

Link: CVE-2026-99009

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-10-23T00:00:00Z

Links: CVE-2026-99009 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-29T19:15:08Z

Weaknesses
  • CWE-362

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

  • CWE-833

    Deadlock