CVE-2026-68432 in Linux
Summary
by MITRE • 08/12/2026
In the Linux kernel, the following vulnerability has been resolved:
vxlan: require CAP_NET_ADMIN in the device netns for changelink
A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net.
vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here.
Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the "require CAP_NET_ADMIN in the device netns for changelink" series.
Found by 0sec automated security-research tooling (https://0sec.ai).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/12/2026
This vulnerability exists within the Linux kernel's VXLAN implementation where insufficient privilege checking allows unauthorized modification of VXLAN tunnel devices across network namespaces. The issue stems from improper capability validation during the changelink operation for VXLAN devices, creating a potential vector for privilege escalation attacks. When a VXLAN device is created or moved between network namespaces, the underlay network namespace may differ from the device's current namespace, leading to inconsistent access controls.
The technical flaw occurs because the rtnl changelink path only validates CAP_NET_ADMIN capability against the device's current network namespace dev_net(dev) rather than the namespace where the underlying tunnel operates. This creates a scenario where an attacker with appropriate privileges in one namespace but not another can manipulate VXLAN configurations, effectively bypassing intended security boundaries. The vxlan_changelink() function performs validation and configuration application against vxlan->net which contains the underlay socket information, yet fails to enforce proper capability checks for this critical namespace.
The operational impact of this vulnerability extends beyond simple privilege escalation as it enables attackers to modify network tunnel configurations in restricted namespaces, potentially allowing them to redirect traffic flows or establish unauthorized communication channels. This weakness particularly affects environments where network namespaces are used for isolation purposes, such as containerized applications or virtualized networking environments. Attackers could exploit this to modify VXLAN parameters, change underlying network interfaces, or manipulate routing behaviors within the affected network namespace.
The fix implements proper capability checking by gating vxlan_changelink() with rtnl_dev_link_net_capable() at the beginning of the operation before any attribute parsing occurs. This approach aligns with established patterns used in other tunnel implementations like ipgre_changelink() and follows the broader "require CAP_NET_ADMIN in the device netns for changelink" series of security improvements. The solution ensures that proper capability validation occurs against the correct network namespace where the underlay operations will take place, preventing unauthorized modifications to VXLAN devices across namespace boundaries.
This vulnerability relates to CWE-284 Access Control and aligns with ATT&CK technique T1068 Privilege Escalation through improper access control mechanisms in kernel space. The issue demonstrates how insufficient capability checking can create security boundaries that are easily circumvented, particularly in complex networking scenarios involving multiple network namespaces. Security researchers identified this weakness using automated tooling, highlighting the importance of systematic vulnerability discovery approaches in kernel security analysis.
The remediation approach mirrors industry best practices for network namespace security by ensuring proper capability validation at the earliest point in the operation lifecycle. This prevents attackers from leveraging namespace transitions to gain unauthorized access to network configurations while maintaining legitimate administrative functionality. The fix reinforces the principle that network configuration operations should require appropriate privileges in all relevant namespaces rather than just the current execution context, establishing proper defense-in-depth measures against cross-namespace privilege escalation attacks.
This vulnerability represents a classic example of how kernel security can be compromised through insufficient privilege validation in complex networking scenarios. The solution demonstrates the importance of maintaining consistent access control policies across all network namespace operations and highlights the value of automated security analysis tools in identifying subtle but critical security weaknesses in operating system components. Organizations should prioritize updating their kernel versions to include this fix, particularly in environments where network isolation through namespaces is critical for security posture maintenance.