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

  - macvlan修正 macvlan_common_newlink() 中的錯誤復原提供了一個 nice 的 repro 以損毀核心
    ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add無效的% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 他也提供了非常詳細的分析 <quote valis> 問題會在建立新的 macvlan 連結時觸發在 MACVLAN_MODE_SOURCE 模式和 MACVLAN_MACADDR_ADD (或 MACVLAN_MACADDR_SET) 參數的情況下較低層裝置已擁有 macvlan 連接埠且從 macvlan_common_newlink() 呼叫的 register_netdevice() 會失敗 (例如因為無效的連結名稱)。在此情況下macvlan_hash_add_source 會從 macvlan_change_sources() 呼叫 / macvlan_common_newlink(): 這會將 vlan 的參照新增至使用 macvlan_source_entry 的連接埠 vlan_source_hash。 vlan 是指向建立中連結之 priv 資料的指標。register_netdevice() 失敗時會將錯誤從 macvlan_newlink() 傳回 rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out且會呼叫 free_netdev()在結構 net_device 上產生一個 kvfree()而該結構仍在連接至較低裝置 macvlan 連接埠的來源項目中參照。現在在 macvlan 連接埠上傳送且具有相符來源 mac 位址的所有封包都會在 macvlan_forward_source() 中觸發釋放後使用。</quote valis> 儘管如此我的修正方法是確保在每次 goto destroy_macvlan_port; 之後無論 @create 值為何我們都會呼叫 macvlan_flush_sources()路徑。
    非常感謝 valis 就此問題採取的後續行動。 (CVE-2026-23209)

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

偵測

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

high Nessus Plugin ID 299121

版本 1.23