Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - Bluetooth：SCO：修复 sco_sock_connect（） sco_sock_connect（） 检查sk_state和sk_type中的争用条件，而无需保留套接字锁定。同一套接字上的两个并发 connect（） syscall 可同时通过检查并进入 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 插件 ID 311668

版本 1.6