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

  - Bluetooth： SCO：修正 sco_sock_connect（） sco_sock_connect（） 檢查中的爭用情形，sk_state和sk_type，而不按住通訊端鎖定。同一通訊端上的兩個並行 connect（） 系統調用都可以通過檢查並輸入 sco_connect（），從而導致釋放後使用。有錯誤的案例涉及三個參與者，並透過額外的記錄檢測得到確認： 執行緒 A （連線）： HCI 中斷連線： 執行緒 B （連線）：sco_sock_connect（sk） sco_sock_connect（sk） sk_state==BT_OPEN sk_state==BT_OPEN （通過，無鎖定） （通過，無鎖定） sco_connect（sk）：sco_connect（sk）：hci_dev_lock hci_dev_lock hci_connect_sco <- blocked -> hcon1 sco_conn_add->conn1 lock_sock（sk） sco_chan_add： conn1->sk = sk sk->conn = conn1 sk_state=BT_CONNECT release_sock hci_dev_unlock hci_dev_lock sco_conn_del： lock_sock（sk） sco_chan_del： sk->conn=NULL conn1->sk=NULL sk_state= BT_CLOSED SOCK_ZAPPED release_sock hci_dev_unlock （未封鎖） hci_connect_sco -> hcon2 sco_conn_add -> conn2 lock_sock（sk） sco_chan_add： sk->conn=conn2 sk_state= BT_CONNECT // 殭屍 sk！release_sock hci_dev_unlock 執行緒 B 將一個 BT_CLOSED + SOCK_ZAPPED 通訊端復活回 BT_CONNECT。
    後續的清理會觸發雙重 sock_put（） 和釋放後使用。同時，conn1 被洩露，因為它在 sco_conn_del（） 清除關聯時成為孤立的。透過以下方式解決此問題： - 在 sco_sock_connect（） 中進行 sk_state/sk_type 檢查之前移動 lock_sock（） 以序列化並發連接嘗試 - 修正 sk_type ！= SOCK_SEQPACKET 檢查以實際傳回錯誤而不僅僅是分配錯誤 - 在 lock_sock（） 之後的 sco_connect（） 中新增狀態重新檢查，以捕捉鎖定之間視窗期間的狀態變更 - 在 sco_chan_add（） 中新增 sco_pi（sk）->conn 檢查以防止通訊端的雙重連接至多個連線 - 在 sco_chan_add 失敗時新增 hci_conn_drop（） 以防止 HCI 連線洩漏 （CVE-2026-43023）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

偵測

Linux Distros 未修補的弱點：CVE-2026-43023

high Nessus Plugin ID 311668

版本 1.22