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

  - macvlan修复 macvlan_common_newlink() 中的错误恢复 valis 提供了造成内核崩溃的良好重现
    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 invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He 也提供了非常详细的分析 <quote valis> 当建立新的 macvlan 链接时会触发该问题使用 MACVLAN_MODE_SOURCE 模式和 MACVLAN_MACADDR_ADD或 MACVLAN_MACADDR_SET 参数时较低的设备已具有 macvlan 端口并且从 macvlan_common_newlink() 调用 register_netdevice() 失败例如因为无效的链路名称。在这种情况下会从 macvlan_change_sources() / macvlan_common_newlink() 调用 macvlan_hash_add_source这会添加对 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()导致附加到较低设备的 macvlan 端口的源条目中仍引用 struct net_device 上的 kvfree()。现在在 macvlan 端口上发送的所有具有匹配源 mac 地址的数据包将触发 macvlan_forward_source() 中的释放后使用。</quote valis> 尽管如此我的修复是确保每当 goto destroy_macvlan_port 时调用 macvlan_flush_sources() 而不管 @create 的值已占用路径。
    非常感谢 valis 关注此问题。 (CVE-2026-23209)

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

检测

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

high Nessus 插件 ID 299121

版本 1.17