ACK: [SRU][J/N/Q][PATCH 0/1] CVE-2026-23209

[Tim Whisonant]

On Thu, Feb 19, 2026 at 03:08:47PM -0500, Ian Whitfield wrote:
> [Impact]
> 
> macvlan: fix error recovery in macvlan_common_newlink()
> 
> valis provided a nice repro to crash the kernel:
> 
> 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 also gave a very detailed analysis:
> 
> <quote valis>
> 
> The issue is triggered when a new macvlan link is created  with
> MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or
> MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan
> port and register_netdevice() called from macvlan_common_newlink()
> fails (e.g. because of the invalid link name).
> 
> In this case macvlan_hash_add_source is called from
> macvlan_change_sources() / macvlan_common_newlink():
> 
> This adds a reference to vlan to the port's vlan_source_hash using
> macvlan_source_entry.
> 
> vlan is a pointer to the priv data of the link that is being created.
> 
> When register_netdevice() fails, the error is returned from
> macvlan_newlink() to rtnl_newlink_create():
> 
>         if (ops->newlink)
>                 err = ops->newlink(dev, &params, extack);
>         else
>                 err = register_netdevice(dev);
>         if (err < 0) {
>                 free_netdev(dev);
>                 goto out;
>         }
> 
> and free_netdev() is called, causing a kvfree() on the struct
> net_device that is still referenced in the source entry attached to
> the lower device's macvlan port.
> 
> Now all packets sent on the macvlan port with a matching source mac
> address will trigger a use-after-free in macvlan_forward_source().
> 
> </quote valis>
> 
> With all that, my fix is to make sure we call macvlan_flush_sources()
> regardless of @create value whenever "goto destroy_macvlan_port;"
> path is taken.
> 
> Many thanks to valis for following up on this issue.
> 
> [Backport]
> 
> The patch was applied cleanly.
> 
> [Fix]
> 
> Questing: Cherry-pick
> Noble: Cherry-pick
> Jammy: Cherry-pick
> Focal: PR on Forgejo
> Bionic: Sent to ESM ML
> Xenial: not affected
> Trusty: not affected
> 
> [Test Case]
> 
> Compile and boot tested.
> 
> [Where problems could occur]
> 
> This fix affects those who use MAC-VLAN to create virtual interfaces that map
> packets to or from specific MAC addresses to a particular interface. An issue
> with this fix would be visible to the user via a kernel crash or networking
> issues with virtual interfaces (containers/VMs).
> 
> Eric Dumazet (1):
>   macvlan: fix error recovery in macvlan_common_newlink()
> 
>  drivers/net/macvlan.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> -- 
> 2.43.0
> 
 
Acked-by: Tim Whisonant <tim.whisonant at canonical.com>