This CVE reveals a namespace boundary bypass in the IPv6 tunnel rtnl interface that has likely existed since IPv6 tunnel support gained netns awareness — meaning the exposure window spans years of kernel versions, not days.
The vulnerability sits in ip6_tnl_changelink(), which failed to verify that the caller held CAP_NET_ADMIN in the tunnel's link namespace (t->net) rather than only checking the device's namespace (dev_net(dev)). Since tunnels can span namespaces, this gap allowed a user with CAP_NET_ADMIN in namespace A to modify tunnel state in namespace B — a lateral movement vector across isolation boundaries that infrastructure-as-code patterns have made increasingly common.
The fix gates the function with rtnl_dev_link_net_capable() before any attribute parsing, which is correct. However, this same capability check template has already been retrofitted onto bridge, bonding, and VLAN changelink paths in previous CVE cycles. The fact that ip6_tunnel was missed suggests other changelink functions in the tree may have the same gap — particularly in device types that haven't been audited in years.
The EPSS score of 0.00163 reflects narrow exploitation preconditions (CAP_NET_ADMIN in a non-initial netns, existing IPv6 tunnel, diverged namespace), but this is not theoretical. Containerized workloads frequently run with CAP_NET_ADMIN in non-initial netns, and the cross-namespace escalation from namespace A to namespace B is a real capability expansion regardless of how sophisticated the attacker is.
Audit your tunnel infrastructure dependency graph first: determine whether any namespace's tunnel state influences routing or connectivity for workloads in OTHER namespaces. That dependency chain — not exploit sophistication — determines the actual blast radius. Then identify all changelink-adjacent rtnl paths in your kernel version and verify they carry the rtnl_dev_link_net_capable() check. This is a pattern fix, not an isolated patch; assume other paths in the tree have the same gap until proven otherwise.