Re: [PATCH net 2/2] ip6_gre: Use cached t->net in ip6erspan_changelink().

[Eric Dumazet]

On Tue, Apr 28, 2026 at 6:58 PM Xiao Liang <shaw.leon@xxxxxxxxx> wrote:
>
> On Tue, Apr 28, 2026 at 7:07 PM Maoyi Xie <maoyixie.tju@xxxxxxxxx> wrote:
> >
> > From: Maoyi Xie <maoyi.xie@xxxxxxxxxx>
> >
> > After commit 5e72ce3e3980 ("net: ipv6: Use link netns in newlink() of
> > rtnl_link_ops"), ip6erspan_newlink() correctly resolves the per-netns
> > ip6gre hash via link_net. ip6erspan_changelink() was not converted in
> > that series and still uses dev_net(dev), which diverges from the
> > device's creation netns after IFLA_NET_NS_FD migration.
> >
> > This re-inserts the tunnel into the wrong per-netns hash, leaving a
> > stale entry in the original creation netns. When that netns is later
> > destroyed, ip6gre_exit_rtnl_net() walks the stale entry, producing a
> > slab-use-after-free reported by KASAN, followed by a kernel BUG at
> > net/core/dev.c (LIST_POISON1) in unregister_netdevice_many_notify().
> >
> > Reachable from an unprivileged user namespace ("unshare --user
> > --map-root-user --net"); cross-tenant scope on container hosts.
> >
> > Note: ip6gre_changelink() (the non-erspan sibling earlier in the same
> > file) already uses the cached t->net correctly. The bug is specific
> > to ip6erspan_changelink() copying the wrong shape.
> >
> > Fixes: 5e72ce3e3980 ("net: ipv6: Use link netns in newlink() of rtnl_link_ops")
>
> The changes look good to me. But why is 5e72ce3e3980 mentioned
> here? It neither introduced nor was intended to fix this bug.

Which patch added the bug then in your opinion?