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/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - Bluetooth： RFCOMM：在不rfcomm_mutex的情况下连接会话套接字 BR/EDR 链路认证时发出的 RFCOMM connect（） 使 lockdep 报告为循环依赖关系，且报告的周期为 rfcomm_mutex 和 hdev->lock 之间的真实 AB/BA。从 HCI 事件路径调用 rfcomm_security_cfm（），该路径已保存 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， 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（） - 连接不必成功，顺序会在页面超时之前记录 - 每次都会报告。只有会话套接字需要与持有的锁定连接，而它不需要：在套接字被放在会话列表中之前，没有其他任何东西可以看到套接字。因此，请先连接它，然后再进行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/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - Bluetooth:RFCOMM:rfcomm_mutex なしでセッションソケットを接続 BR/EDR リンクが認証されている際に発行される RFCOMM connect() により、lockdep は循環依存関係を報告します。報告されるサイクルは、rfcomm_mutex と hdev->lock の間の実際の AB/BA となります。rfcomm_security_cfm() は、すでに hdev->lock を保持している HCI イベントパスから呼び出されます: 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() は逆に同じ 2 つのロックを取ります: 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] の取得を試行しているが、タスクはすでに lock: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() を呼び出すと、毎回、接続が成功する必要はありません。この順序はページタイムアウトの前に記録されます。セッションソケットだけが、ロックされた状態で接続する必要がありますが、そうではありません:セッションリストに配置されるまで、他の何もソケットを見ることができません。したがって、最初に接続し、後でrfcomm_mutexを行うことで、HCI イベントパスをrfcomm_mutexから遠ざけるのではなく、rfcomm_mutex -> hdev->lock の順番を永久に削除します。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() はこうした DLC を RFCOMM_CLOSED でマークするようになり、再度 rfcomm_mutex を保持すると rfcomm_dlc_open() はそのマークをチェックし、DLC をアタッチする代わりにソケットをドロップします。オープンが開始されるとマークがクリアされるため、再利用される DLC は影響を受けません。これは、rfcomm_dlc_open()の呼び出し元、ソケット、ttyレイヤーの両方を対象とします。
    (CVE-2026-99009)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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.
    (CVE-2026-99009)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Published	Updated	Severity
371463	Linux Distros 未修補弱點：CVE-2026-99009	Nessus	Misc.	10/23/2026	11/7/2026	low
371463	Linux Distros 未修补的漏洞：CVE-2026-99009	Nessus	Misc.	10/23/2026	11/7/2026	low
371463	Linux Distros のパッチ未適用の脆弱性: CVE-2026-99009	Nessus	Misc.	10/23/2026	11/7/2026	low
371463	Linux Distros Unpatched Vulnerability : CVE-2026-99009	Nessus	Misc.	10/23/2026	11/7/2026	low

Detections

Analytics

Plugins Search

low

low

low

low