CVE-2026-72052

The vulnerability in ip6gre_changelink() and ip6erspan_changelink() stems from a capability check scoped to the wrong network namespace. The code checked CAP_NET_ADMIN against dev_net(dev)—the device's namespace—while the tunnel actually lived in a separate namespace (t->net). In single-namespace environments, these contexts coincide and the bug never manifests. In containerized deployments where network plugins operate across namespace boundaries, a process holding CAP_NET_ADMIN in one netns could modify tunnels living in another. The fix introduces rtnl_dev_link_net_capable() checks at the operation's entry point, before any attribute parsing. This forces handlers to explicitly consider both namespace contexts rather than relying on inherited assumptions about which context matters. For defenders: verify your kernel version includes this patch if you run ip6gre or ip6erspan tunnels across different network namespaces. The practical risk is highest in container orchestrators where network plugins hold CAP_NET_ADMIN in a pod's netns while tunnels exist in the host or another namespace. Audit your tunnel configurations to confirm which netns your ip6gre/ip6erspan interfaces actually reside in versus where your network management processes hold privileges. Beyond this specific fix, treat the underlying pattern as a class of vulnerability. Other tunnel types—gre, sit, vti, and their ipv4 variants—use the same changelink infrastructure and likely have identical dual-netns capability scoping issues. The kernel's rtnl layer does not enforce consistent capability semantics across handlers; each handler must get it right independently. This structural gap means more tunnel-related CVEs in this family should be expected. If you're maintaining kernel code in similar subsystems, audit any changelink or dual-netns operations for the same capability scoping pattern.

Reviewed through automated stages and approved by a human before publication.