CVE-2026-72055 is a netns boundary bypass in the vti6_changelink() kernel function. The vulnerability allows an attacker with CAP_NET_ADMIN in one network namespace to modify tunnel parameters for a tunnel residing in a different namespace where they lack those privileges. The root cause: the standard rtnl changelink path validates capabilities against dev_net(device) but never checks the tunnel's own netns when the two diverge — a classic dual-reference object handled by a single-context API.
The fix gates the function on rtnl_dev_link_net_capable() before any attribute parsing, not merely to prevent unauthorized writes but to block partial state exposure during the parse phase. An attacker could have extracted tunnel configuration details from the intermediate parse state before the capability check would have fired — reconnaissance value that compounds the write vulnerability.
The CAP_NET_ADMIN precondition does not meaningfully contain this risk in practice. Container configurations frequently grant this capability by default, and partial container escapes often land attackers at CAP_NET_ADMIN as a starting point rather than a ceiling. In shared-tenancy Kubernetes clusters or multi-tenant hosts, the blast radius is the real concern: one-hop lateral movement across namespace boundaries into infrastructure the attacker shouldn't touch.
This is not an isolated bug — it is a manifestation of a recurring genetic weakness in kernel networking. The pattern of checking one netns reference but not both when objects span two namespaces has appeared in nf_tables cross-netns vulnerabilities, cgroup delegation bugs, and ipvs netns handling. Each fix follows the same pattern: gate earlier, check both contexts. The historical pattern shows these fixes cascade into three to seven sibling vulnerabilities within six months of publication.
Audit your tunnel implementations (vti, GRE, SIT) for the same gap. The survivorship question is uncomfortable: vti6 received this fix likely because someone had a reason to look, not because it was uniquely flawed. Less-scrutinized alive code with the same dual-netns semantics is where the next vulnerability in this family probably hides.