CVE-2026-68142 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
geneve: 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 geneve->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 geneve->net can rewrite a geneve device whose underlay lives in geneve->net.
geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here.
Gate geneve_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).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/10/2026
This vulnerability resides within the Linux kernel's Geneve tunneling implementation, specifically addressing a privilege escalation issue through improper capability checks during network device configuration changes. The flaw occurs in the geneve_changelink() function which manages link configuration modifications for Geneve tunnels, creating a security boundary violation that allows malicious actors to manipulate network devices across namespace boundaries.
The technical root cause stems from inadequate capability verification during the tunnel changelink operation. When a Geneve device is moved between network namespaces, the system maintains two distinct network namespaces: dev_net(dev) which represents the current execution context and geneve->net which contains the underlay network namespace where the actual tunnel sockets operate. The existing implementation only validates CAP_NET_ADMIN permissions against the device's current namespace dev_net(dev) but fails to verify administrative privileges in the underlay namespace geneve->net where critical socket operations actually occur.
This design flaw enables attackers with appropriate privileges in one namespace to modify tunnel configurations in another namespace where they lack proper authorization. The vulnerability manifests when geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() function pair attempt to reopen underlay sockets in the target network namespace through geneve_sock_add() which exclusively uses the geneve->net context. This creates an attack surface where unauthorized modifications can be silently applied to network tunnel configurations.
The operational impact of this vulnerability extends beyond simple privilege escalation, potentially enabling attackers to manipulate network traffic flows, redirect communication channels, or establish persistent backdoors through compromised tunnel configurations. Network administrators with elevated privileges in one namespace could exploit this weakness to gain unauthorized control over Geneve tunnels operating in different namespaces, creating a significant security risk in multi-tenant environments or systems utilizing containerized networking.
This issue aligns with CWE-284 Access Control Issues and specifically relates to improper privilege checks in network kernel subsystems. The vulnerability follows patterns commonly seen in the ATT&CK framework under T1068 Exploitation for Privilege Escalation and T1566 Impairing Defenses, where attackers leverage kernel-level weaknesses to bypass security controls. The fix implementing rtnl_dev_link_net_capable() at the function's entry point mirrors the approach used in ipgre_changelink() and other tunnel implementations within the Linux kernel, establishing consistent capability checking across similar network device operations.
Security mitigations should focus on enforcing proper capability validation before any configuration attributes are processed, ensuring that all network device modifications require appropriate administrative privileges in both the current namespace and the target operational namespace. Organizations should prioritize applying kernel updates that implement this capability check, particularly in environments where multiple network namespaces are utilized or where containerized applications rely on Geneve tunneling for inter-container communication. The solution addresses a broader category of vulnerabilities identified by automated security research tools, highlighting the importance of comprehensive capability validation in kernel networking subsystems.