CVE-2026-23209

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macvlan: fix error recovery in macvlan_common_newlink()<br /> <br /> valis provided a nice repro to crash the kernel:<br /> <br /> ip link add p1 type veth peer p2<br /> ip link set address 00:00:00:00:00:20 dev p1<br /> ip link set up dev p1<br /> ip link set up dev p2<br /> <br /> ip link add mv0 link p2 type macvlan mode source<br /> ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20<br /> <br /> ping -c1 -I p1 1.2.3.4<br /> <br /> He also gave a very detailed analysis:<br /> <br /> <br /> <br /> The issue is triggered when a new macvlan link is created with<br /> MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or<br /> MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan<br /> port and register_netdevice() called from macvlan_common_newlink()<br /> fails (e.g. because of the invalid link name).<br /> <br /> In this case macvlan_hash_add_source is called from<br /> macvlan_change_sources() / macvlan_common_newlink():<br /> <br /> This adds a reference to vlan to the port&amp;#39;s vlan_source_hash using<br /> macvlan_source_entry.<br /> <br /> vlan is a pointer to the priv data of the link that is being created.<br /> <br /> When register_netdevice() fails, the error is returned from<br /> macvlan_newlink() to rtnl_newlink_create():<br /> <br /> if (ops-&gt;newlink)<br /> err = ops-&gt;newlink(dev, &amp;params, extack);<br /> else<br /> err = register_netdevice(dev);<br /> if (err