Re: [PATCH net v3 2/2] ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().

[Xiao Liang]

On Thu, May 21, 2026 at 8:58 PM Maoyi Xie <maoyixie.tju@xxxxxxxxx> wrote:
>
> Hi Xiao,
>
> Thanks for the review, and sorry about the wrong Fixes tag.
> 5e72ce3e3980 is not where the bug starts. The dev_net(dev)
> vs t->net divergence first became reachable in commit
> 61220ab34948 ("vti6: Enable namespace changing"), which
> dropped NETIF_F_NETNS_LOCAL and let vti6 devices move through
> IFLA_NET_NS_FD. v4 will use that on both 1/2 and 2/2. Same
> shape Jakub took for the sibling fix 1d324c2f43f7.
>
> Thanks also for the ns_capable suggestion. The top of the
> switch case only checks dev_net(dev)->user_ns. After migration
> that is the attacker's netns. With the v3 patch the lookup
> uses self->net. The else branch still sets t = self, and
> vti6_update() inserts the device into the creation netns
> hash. I reproduced this on a v3 kernel. An unprivileged
> caller in the migrated netns picked params absent from
> init_net. The SIOCCHGTUNNEL returned 0. SIOCGETTUNNEL in
> init_net for those params returned the migrated device.
> v4 adds ns_capable(self->net->user_ns, CAP_NET_ADMIN) before
> the lookup. With that check the call returns -EPERM.

I think a similar issue also exists in the rtnetlink path.
rtnl_newlink() requires CAP_NET_ADMIN in the link netns only when
the IFLA_LINK_NETNSID attr is supplied. However, this attr is not
required when modifying tunnel parameters. As a result, a user with
capabilities only in the device netns can modify tunnel parameters in
the link netns, including endpoint addresses and keys. I'm not sure
if this behavior is expected.

>
> I will send v4 shortly.
>
> Thanks,
> Maoyi