This CVE exposes a namespace boundary gap in how the Linux kernel handles GENEVE tunnel reconfiguration. When a GENEVE tunnel has a sticky underlay network namespace (geneve->net) that differs from its primary device namespace (dev_net(dev)), the changelink operation must verify CAP_NET_ADMIN against both namespaces. The original implementation only checked dev_net(dev), allowing a caller with network admin privileges in the device namespace but not the underlay to rewrite tunnel configuration and trigger socket reopening in the privileged namespace.
The fix applies rtnl_dev_link_net_capable() before any attribute parsing, gating the entire operation against the underlay namespace. This pattern was already established in ipgre and similar tunnels, indicating this is not a novel discovery but an instance of a recurring vulnerability class where tunnel operations span multiple namespaces without complete capability verification.
What makes this more serious than CVSS suggests: GENEVE underpins VXLAN-GPE, Kubernetes CNI overlays, and multi-tenant cloud infrastructure. An attacker who gains CAP_NET_ADMIN in a container namespace could potentially pivot into the underlay network fabric and access traffic belonging to other tenants on the same host—a risk dimension the score doesn't capture.
Defenders should verify their kernels have the fix (commit matching the GENEVE changelink capability pattern), audit other tunnel types using sticky underlay netns for similar gaps, and recognize that the EPSS score likely underestimates risk in cloud/container environments where GENEVE is prevalent. The existence of automated tooling finding this pattern suggests other tunnel variants may remain unpatched.