Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - Bluetooth： 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] 警告： 偵測到可能的循環鎖定相依性 kworker/u131：1/1128 正在嘗試取得 lock： rfcomm_mutex， at： rfcomm_security_cfm+0x31/0x3e0 [RFCOMM] 但工作已保留鎖定： hci_cb_list_lock， 在：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（） - 連接不必成功，順序會在頁面逾時之前記錄 - 每次都會報告。只有工作階段通訊端必須與持有的鎖定連接，而它不需要：在將通訊端放在工作階段清單之前，其他任何東西都無法看到該通訊端。因此，先連接它，然後再進行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_dlc_close（） 現在會以 RFCOMM_CLOSED 標示此類 DLC，而 rfcomm_dlc_open（） 會在再次保持rfcomm_mutex標記後檢查標記，並刪除通訊端，而不是附加 DLC。開啟開始時，此標記會清除，因此重複使用的 DLC 不會受到影響。這涵蓋了 rfcomm_dlc_open（） 的呼叫者、通訊端和 tty 層。
    (CVE-2026-99009)

請注意，Nessus 依賴供應商報告的套件存在。

偵測

Linux Distros 未修補弱點：CVE-2026-99009

low Nessus Plugin ID 371463

版本 1.6