Linux Kernel EUVD-2026-57040

Exploitation requires three concurrent conditions: (1) a vxlan device where the device network namespace (dev_net) differs from the underlay namespace (vxlan->net) - this arises when a vxlan device is created in one netns and moved to another, or when a container-namespace vxlan device references a host-namespace underlay socket, a topology common in container CNI plugins; (2) the attacker must hold CAP_NET_ADMIN in the device netns but NOT in the underlay netns; and (3) local code execution with access to raw RTNL netlink sockets. Exploitation is specifically limited by the non-default mismatched-namespace configuration - standard deployments where dev_net(dev) equals vxlan->net are entirely unaffected, as the privilege check is sufficient in that case. Remote unauthenticated exploitation is not possible; unprivileged local users without CAP_NET_ADMIN in the device netns cannot exploit this flaw.

The NVD CVSS 8.8 vector (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) reflects a local privilege escalation with scope change - the most realistic impact being cross-namespace network configuration manipulation affecting all tenants sharing the underlay namespace. The local attack vector limits mass exploitation, but the combination of PR:L and S:C is significant in container-heavy environments where CAP_NET_ADMIN is routinely granted to application pods. The 17% EPSS score is notably elevated for a kernel flaw without confirmed exploitation, and even a mid-sized municipal IT team in kielce operating a shared Kubernetes cluster should treat this as an urgent patching priority rather than a low-probability theoretical risk. No CISA KEV listing and no public exploit code are confirmed at time of analysis, so while exploitation probability is meaningful, it has not yet materialized into observed attacks. The AC:L rating in the provided CVSS vector may be optimistic: the mismatched-namespace condition (dev_net ≠ vxlan->net) is non-default and requires either deliberate device migration across namespaces or a scenario where containers with NET_ADMIN interact with host-anchored vxlan underlay sockets - defenders should verify whether their deployments actually expose this configuration before treating this as an immediate emergency. Standard single-namespace deployments are not vulnerable.

An attacker with code execution inside a container granted NET_ADMIN capability identifies a vxlan tunnel device whose underlay netns is anchored in the host kernel namespace rather than the container namespace. Using raw netlink sockets, the attacker issues a crafted RTM_NEWLINK changelink message targeting the vxlan device; the kernel accepts the operation because CAP_NET_ADMIN is confirmed only in the container's device netns, allowing vxlan_changelink() to apply attacker-controlled configuration - including reopening the underlay UDP socket - against the host-level underlay namespace. No public proof-of-concept code has been identified at time of analysis.