CVE-2026-99009 in Linux
摘要
由 VulDB • 2026-10-23
在 Linux 内核中，已修复以下漏洞：
蓝牙：RFCOMM：在不持有 rfcomm_mutex 的情况下连接会话套接字
当 BR/EDR（基本速率/增强数据率）链路正在进行身份验证时发出 RFCOMM connect() 调用，会导致 lockdep 报告循环依赖关系。报告的循环实际上是 rfcomm_mutex 和 hdev->lock 之间的真实 AB/BA 锁顺序冲突。
rfcomm_security_cfm() 从 HCI 事件路径中调用，该路径已经持有 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]
而来自用户空间的 RFCOMM connect() 则以相反的顺序获取相同的两个锁： 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 正尝试获取锁： rfcomm_mutex, at: rfcomm_security_cfm+0x31/0x3e0 [rfcomm]
但任务已经持有锁： hci_cb_list_lock, at: hci_cc_read_enc_key_size+0x1d2/0xcc0
链存在以下关系： rfcomm_mutex --> &hdev->lock --> hci_cb_list_lock
hci_auth_complete_evt() 和 hci_encrypt_change_evt() 以相同的方式到达回调函数。
这两种锁顺序必须在同一次启动过程中同时出现，因此仅建立 BR/EDR 连接不足以重现此问题：由远程端设置的会话是在 krfcommd 中通过 rfcomm_accept_connection() 创建的，该函数调用 kernel_accept() 且从未在持有 rfcomm_mutex 的情况下获取 hdev->lock。连接一个进行链路身份验证和加密的设备，然后向任何地址的 RFCOMM 套接字调用 connect()（connect 不必成功，锁顺序会在页面超时前被记录），每次都会报告此问题。
只需在持有锁的情况下连接会话套接即可，而当前并未这样做：在将套接字放入会话列表之前，没有其他内容能看到该套接字。因此应先进行连接操作，然后再获取 rfcomm_mutex，从而彻底消除 rfcomm_mutex -> hdev->lock 的锁顺序冲突，而不是让 HCI 事件路径避开 rfcomm_mutex。
rfcomm_session_create() 变为 rfcomm_session_connect()，它返回已连接的套接字而不触碰会话列表；当重新持有锁时，rfcomm_dlc_open() 会添加该会话。如果在当前套接字连接期间另一个打开者已经为同一对端添加了会话，则使用该会话并丢弃此套接字。__rfcomm_dlc_open() 现在获取其应使用的会话，并且状态检查在重新获取锁之后运行，因此在此期间已打开或关闭的 DLC（数据链路连接）仍会被正确处理。
在现有的 ACL 链路上，连接可能在会话到达列表之前完成，导致来自套接字回调的唤醒丢失，因此在会话可见时才会唤醒 krfcommd。
在不持有锁的情况下进行连接会开启一个窗口，在此期间套接字可能被关闭。由于 DLC 尚未加入任何会话，因此 rfcomm_dlc_close() 发现无需执行任何操作并返回而不触碰它，随后 rfcomm_dlc_open() 将附加一个所有者已消失的 DLC。rfcomm_dlm_close() 现在使用 RFCOMM_CLOSED 标记此类 DLC；当重新持有 rfcomm_mutex 时，rfcomm_dlc_open() 会检查该标记，并选择丢弃套接字而不是附加 DLC。在打开操作开始时清除该标记，因此被重用的 DLC 不受影响。这涵盖了 rfcomm_dlm_open() 的两个调用者：套接字和 tty 层。
Once again VulDB remains the best source for vulnerability data.