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

  - phonet/pep：围绕转发的 sk_receive_skb（） 禁用 BH 网络接收路径通常从 softirq 上下文运行，但采用套接字锁定的协议可能将数据包存储在 backlog 中，然后从进程上下文进行处理。在这种情况下，release_sock（） -> __release_sock（） 会终止具有 spin_unlock_bh（） 的 slock，然后在启用下半部的情况下调用 sk->sk_backlog_rcv（）。典型的 sk_backlog_rcv 处理程序会处理其 backlog 正在被耗尽的套接字，因此条目时的 BH 状态与它们所接触的 slock 无关。pep_do_rcv（） 则不同：当入站 skb 以现有 PEP 管道为目标时，它会通过 sk_receive_skb（） 将该 skb 转发到不同的 *子* 套接字。此帮助程序采用包含 bh_lock_sock_nested（） 的子锁，后者只是 spin_lock_nested（），并假定 BH 已关闭。因此，在 BH 开启（进程路径）和 BH 关闭（softirq 路径）时，都会获取相同的子锁：进程环境 softirq context --------------- --------------- release_sock（listener） __netif_receive_skb（）
    __release_sock（） phonet_rcv（） spin_unlock_bh（） __sk_receive_skb（listener） [BH 已启用] [BH 已禁用] sk_backlog_rcv： sk_backlog_rcv： pep_do_rcv（） pep_do_rcv（） sk_receive_skb（child） sk_receive_skb（child） bh_lock_sock_nested（child） bh_lock_sock_nested（child） => SOFTIRQ-ON-W => IN-SOFTIRQ-W Lockdep 将此标记为不一致的锁定状态， 并且如果同一 CPU 中的 softirq 尝试接收相同的子套接字，而其锁在启用 BH 的路径中保留，则可能变成真正的自死锁：警告：不一致的锁定状态不一致 {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} 使用。
    （slock-AF_PHONET/1）{+.?.}-{3:3}， at： __sk_receive_skb+0x1cf/0x900 __sk_receive_skb net/core/sock.c：563 sk_receive_skb include/net/sock.h：2022 [内联] pep_do_rcv net/phonet/pep.c：675 sk_backlog_rcv include/net/sock.h：1190 __release_sock net/core/sock.c：3216 release_sock net/core/sock.c：3815 pep_sock_accept net/phonet/pep.c：879 将转发的 sk_receive_skb（） 封装在 local_bh_disable（） / local_bh_enable（） 中，以便始终使用BH 关闭。local_bh_disable（） 在 softirq 路径上安全嵌套。通过内部 syzkaller 模糊测试发现;linux-6.1.y syzbot 仪表板上也存在与 extid 44f0626dd6284f02663c 相同的根源。在 KASAN + LOCKDEP + PROVE_LOCKING 下转载，复制品： https://pastebin.com/A3t8xzCR （CVE-2026-64177）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2026-64177

medium Nessus 插件 ID 328087

版本 1.18