CVE-2026-68432 is a namespace boundary confusion vulnerability in the VXLAN tunnel driver. The issue: when a VXLAN device is moved into a non-default network namespace, the device lives in one namespace (the overlay) but its underlay socket lives in a different 'sticky' namespace (vxlan->net) where encapsulated traffic actually originates. The changelink netlink operation was checking CAP_NET_ADMIN only against the device's namespace—dev_net(dev)—but the operation's effects, specifically reopening the underlay socket, occur in vxlan->net. This allowed a user with container-level CAP_NET_ADMIN in one namespace to reconfigure tunnel parameters that execute in a different namespace where they lack that capability.
The fix uses rtnl_dev_link_net_capable() to gate the entire operation before any attribute parsing begins—a fail-early defense-in-depth approach. This is analytically significant because the same patch series addresses similar issues in ipgre, suggesting this namespace boundary confusion is a systemic pattern in Linux tunnel drivers rather than a one-off VXLAN oversight. The changelink path was never retrofitted to understand that any operation touching the sticky netns is a cross-boundary operation.
For defenders in multi-tenant container environments: the question isn't whether you trust users with CAP_NET_ADMIN in one netns—it's whether that trust extends when that netns is merely the overlay and the underlay lives elsewhere. Review any workloads granted CAP_NET_ADMIN in overlay namespaces, particularly in environments where VXLAN devices may span namespace boundaries. The EPSS is low (0.00129), which likely reflects the kernel networking expertise required to exploit it rather than absence of risk—this class of namespace boundary confusion in tunnel drivers has existed largely undetected for over a decade, and the discovery of this pattern suggests similar issues likely remain in other tunnel drivers and underlay socket lifecycle paths not covered by this series.