Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1359 CNY

100%

Buy Us a Coffee

CVE-2026-99009— Bluetooth: RFCOMM: connect the session socket without rfcomm_mutex

Quick assessment

Affected

Linux Linux

Exploitation

No confirmed in-the-wild exploitation; assess based on exposure

Recommended action

Check the vendor advisory and references for a fixed version. If immediate upgrade is impossible, restrict exposure and increase monitoring.

在 Linux 内核中，以下漏洞已被修复：蓝牙：RFCOMM：在不持有 rfcomm_mutex 的情况下连接会话套接字当 BR/EDR 链路正在进行身份验证时，若此时发起 RFCOMM 的 connect() 调用，lockdep 会报告存在循环依赖。该报告的循环确实反映了 rfcomm_mutex 与 hdev->lock 之间的真实 AB/BA 死锁顺序。 rfcomm_security_cfm() 函数从 HCI 事件路径中被调用，而该路径已经持有 hdev->lock：而来自用户空间的 RFCOMM

AI Predicted 5.5 Difficulty: Moderate EPSS 0.17% · P6 Updated Oct 23, 2026

Possible ATT&CK Techniques 1 AI

T1190 · Exploit Public-Facing Application

Affected Version Matrix 15

Vendor	Product	Version Range	Status
Linux	Linux	`82425b14f0fb22e46cfddc56d6465570f5ed0ce6< 4dc3d5a004b8fd59f3c905631dbb18cb601b1b41`	affected
		`1b7841ffad08e911e8c4b9470f3fa08423568940< d2206e8c78be69d21d4f5343c3e99fbaeef41cbb`	affected
		`946d76db77ee5f922968ce558629ae47b381e3fc< cc7732b8549ecb6f02457edeb8db1f6d255e381c`	affected
		`fbf7961964a6e93360179f64712320ae9a1e9577< f492de11b325446b0b11bc2eb86e1f546eaa61b6`	affected
		`759c185d0bbdb131357408f50b8735e04ed3caff< ac022970e9fb0a5f7e7d1f6c8e104c1ed924dd1c`	affected
		`62ce8b33eb238cf18c15207332fbdc26d858f592`	affected
		`3873f3449701b3dc98cba577923be6493598e7a1`	affected
		`7ded3264106418c6456ccceaafd9fda596ce12c3`	affected
… +7 more rows

Get alerts for future matching vulnerabilities Log in to subscribe

Vulnerability Information

Have questions about the vulnerability? See if Shenlong's analysis helps!

View Shenlong Deep Dive ↗

Although we use advanced large model technology, its output may still contain inaccurate or outdated information.Shenlong tries to ensure data accuracy, but please verify and judge based on the actual situation.

Vulnerability Title

Bluetooth: RFCOMM: connect the session socket without rfcomm_mutex

Source: CVE Program / CVE List V5

Vulnerability 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.

Source: CVE Program / CVE List V5

CVSS Information

N/A

Source: CVE Program / CVE List V5

Vulnerability Type

N/A

Source: CVE Program / CVE List V5

Affected Products

Vendor	Product	Affected Versions	CPE	Subscribe
Linux	Linux	82425b14f0fb22e46cfddc56d6465570f5ed0ce6 ~ 4dc3d5a004b8fd59f3c905631dbb18cb601b1b41	-
Linux	Linux	6.6.157 ~ 6.6.160	-

II. Public POCs for CVE-2026-99009

#	POC Description	Source Link	Shenlong Link

AI-Generated POC Premium

No public POC found.

III. Intelligence Information for CVE-2026-99009

请登录查看更多情报信息。

Patches & Fixes for CVE-2026-99009 (5)

https://www.cve.org/CVERecord?id=CVE-2026-99009

Same Patch Batch · Linux · 2026-10-23 · 217 CVEs total

CVE-2026-98959	9.8 CRITICAL	btrfs: fix xattr replace when multiple xattrs are packed in the same item
CVE-2026-99078	9.8 CRITICAL	net/mlx5e: Prevent stale XSK buffer release on MPWQE refill retry
CVE-2026-99079	9.8 CRITICAL	net/mlx5e: Prevent stale XSK buffer release on refill retry
CVE-2026-98988	8.8 HIGH	namespace: keep covered mounts covered in OPEN_TREE_NAMESPACE
CVE-2026-99083	8.8 HIGH	ksmbd: fix heap out-of-bounds write in krb5_authenticate()
CVE-2026-99082	8.8 HIGH	KVM: x86: Use active memslots for the per-vCPU MMIO cache
CVE-2026-98870	8.8 HIGH	ksmbd: remove stale channels from all sessions on teardown
CVE-2026-98980	8.8 HIGH	namei: don't reveal overmounted entries in refwalk
CVE-2026-98981	8.8 HIGH	namespace: unhash a dentry before detaching the mounts on it
CVE-2026-99042	8.4 HIGH	io_uring/net: populate CONNECT filter fields for 24-byte sockaddr_in6
CVE-2026-98978	8.4 HIGH	namespace: never expire a locked mount
CVE-2026-99064	8.1 HIGH	cipso: adjust cached option offsets when removing CIPSO
CVE-2026-98968	8.1 HIGH	amt: send the relay's General Query directly from the receive path
CVE-2026-98993	7.8 HIGH	namespace: don't inherit MNT_UMOUNT in clone_mnt()
CVE-2026-99053	7.8 HIGH	tipc: hold a reference to nodes found by link name
CVE-2026-99054	7.8 HIGH	tipc: destroy topsrv workqueues before closing connections
CVE-2026-99056	7.8 HIGH	strparser: make sure __strp_recv isn't running before tearing down the parser
CVE-2026-99002	7.8 HIGH	drm/vmwgfx: validate pitch coming from userspace
CVE-2026-98899	7.8 HIGH	netfilter: ipset: mark the rcu locked areas properly
CVE-2026-99014	7.8 HIGH	Bluetooth: hci_sync: Fix command skb lifetime during scan setup

Showing top 20 of 217 CVEs. View all on vendor page → →

IV. Related Vulnerabilities

Same product: Linux

Same vendor: Linux