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

  - phonet/pep：停用轉寄 sk_receive_skb（） 周圍的 BH，網路接收路徑通常是從 softirq 內容執行，但採用通訊端鎖定的通訊協定可能會將封包儲存在待辦專案中，稍後從處理程序內容處理。在這種情況下，release_sock（） -> __release_sock（） 會使用 spin_unlock_bh（） 刪除鎖定，然後呼叫啟用下半部的 sk->sk_backlog_rcv（）。一般 sk_backlog_rcv 處理常式會處理正在清空待辦專案的通訊端，因此進入時的 BH 狀態與它們接觸的鎖定無關。pep_do_rcv（） 則不同：當入站 skb 以現有 PEP 管道為目標時，它會透過 sk_receive_skb（） 將 skb 轉送至不同的 *子* 通訊端。該協助程式使用 bh_lock_sock_nested（） 獲取子鎖，這只是 spin_lock_nested（），並假設 BH 已經關閉。因此，最終會在 BH 開啟 （處理程序路徑） 和關閉 BH （softirq 路徑） 的情況下取得相同的子鎖： 處理程序上下文 softirq 上下文 --------------- --------------- release_sock（接聽程式） __netif_receive_skb（）
    __release_sock（） phonet_rcv（） spin_unlock_bh（） __sk_receive_skb（接聽程式） [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（） 中，以便一律使用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 Plugin ID 328087

版本 1.14