CVE-2026-63921

In the Linux kernel, the following vulnerability has been resolved:

ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().

After patch 1/2 in this series, vti6_update() unlinks and relinks the tunnel through t->net. vti6_siocdevprivate() still uses dev_net(dev) for the collision lookup. For a tunnel moved through IFLA_NET_NS_FD, dev_net(dev) is the new netns, not t->net.

SIOCCHGTUNNEL on a migrated tunnel then runs:

net = dev_net(dev) /* migrated netns / t = vti6_locate(net, &p1, false) / misses target in t->net / … t = netdev_priv(dev) vti6_update(t, &p1, false) / mutates t->nets hash */

A caller in the migrated netns picks params that match a tunnel in the creation netns. The lookup in dev_net(dev) finds nothing. vti6_update() prepends the migrated tunnel at the head of the creation netns hash bucket for those params. Later lookups in the creation netns resolve to the migrated device. xfrm receive delivers the matched packets through a device the caller controls.

Reachable from an unprivileged user namespace (unshare –user –map-root-user –net). Cross tenant scope on container hosts.

Switch the SIOCCHGTUNNEL path on a non fallback device to use t->net for the lookup. The lookup now matches the netns vti6_update() operates on.

Also add ns_capable(self->net->user_ns, CAP_NET_ADMIN) before the lookup. The check at the top of the case is against dev_net(dev)->user_ns, which after migration is the attackers netns. A caller there can pick params absent from self->net, the lookup returns NULL, t becomes self, and vti6_update() inserts the device into the creation netns hash. The new check requires CAP_NET_ADMIN in the creation netns user_ns too.

SIOCADDTUNNEL and SIOCCHGTUNNEL on the fallback device keep dev_net(dev), which equals init_net there.

Weakness

The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

Affected Software

Potential Mitigations

• Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
• Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
• Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
• For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
• For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
• One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.

Related Attack Patterns

• https://cwe.mitre.org/data/definitions/665.html

References

• https://git.kernel.org/stable/c/1acfb7d9c6fc7e209ed7789392697e97e03edd33
• https://git.kernel.org/stable/c/44d2ff7d2178503b93151140a45dfa2ad49c9906
• https://git.kernel.org/stable/c/596f6354c96a891e58c04a09cbfb7b0d1ec00dab
• https://git.kernel.org/stable/c/853f6ea482dfcd3404bbef458ab4d68364eed838
• https://git.kernel.org/stable/c/8b484efd5cb4eeef9021a661e198edc5349dacf6
• https://git.kernel.org/stable/c/94ff740a7f9ef5c010784a325dca00cbf228f941
• https://git.kernel.org/stable/c/d2236348414bdd6558385f35aa7fdc9bf5634011
• https://git.kernel.org/stable/c/df42ac708acc3399bbb6dc5ca16e0540adda7bbf