CVE-2026-68142

What it actually does

CVE-2026-68142 is a Linux kernel authorization bypass in the Geneve virtual tunnel driver. The vulnerable changelink path validates CAP_NET_ADMIN only in the Geneve device network namespace, but the operation can also affect the Geneve device's sticky underlay network namespace. If a process has network-administration capability in the device namespace but not in the underlay namespace, it may still modify Geneve tunnel configuration and cause the kernel to reopen or reconfigure underlay sockets in a namespace where the caller should not have administrative control. The practical impact is unauthorized tunnel reconfiguration across network-namespace boundaries, potentially affecting encapsulated traffic routing, tunnel availability, isolation assumptions, and overlay-network behavior.

Why it matters to the business

Organizations using Linux Geneve tunnels, container networking, virtualization overlays, or software-defined networking may face unauthorized network configuration changes from a less-privileged namespace. This can disrupt overlay connectivity, redirect or blackhole traffic, weaken tenant or workload isolation, and cause difficult-to-diagnose network outages. The issue is newly published, is not currently listed in CISA KEV, and has no known mature public exploit indicated, but it should still be prioritized for systems that delegate CAP_NET_ADMIN inside containers or network namespaces.

How an attack unfolds

An attacker first obtains execution in a context that has CAP_NET_ADMIN in one network namespace, such as a privileged container, network-management helper, or delegated namespace. The attacker identifies or gains access to a Geneve tunnel device whose device namespace differs from its underlay namespace. On vulnerable kernels, the attacker sends a rtnetlink changelink request to modify the Geneve device. The kernel authorizes the request only against the device network namespace, then applies the new Geneve configuration against the underlay namespace, including quiescing and reopening underlay sockets. This lets the attacker modify tunnel parameters that influence traffic handling in a namespace where they lack the required administrative capability. Depending on deployment, this may allow denial of service, traffic misdirection, overlay-network disruption, or policy bypass across namespace boundaries.

How to fix it

Apply a Linux kernel update that includes the Geneve changelink authorization fix requiring CAP_NET_ADMIN in the relevant device link network namespace before parsing or applying attributes. If vendor fixed package versions are not yet available, track advisories from the Linux distribution, appliance vendor, container platform, or cloud image provider and deploy the first kernel build that includes the upstream fix. As interim mitigation, reduce exposure by avoiding delegation of CAP_NET_ADMIN to untrusted containers or workloads, disabling or restricting privileged containers, limiting access to rtnetlink interface-management operations, removing unused Geneve tunnel support where feasible, and tightening namespace/network administration controls in orchestration platforms.

How to confirm the fix worked

Confirm the running kernel includes the fix from the vendor or upstream stable branch, then reboot into the updated kernel and verify with uname/package inventory that the fixed kernel is active rather than merely installed. Validate exposure by checking whether Geneve interfaces are present and whether untrusted workloads or users can obtain CAP_NET_ADMIN in any network namespace. Functional validation can include attempting a Geneve changelink operation from a namespace that has CAP_NET_ADMIN only in the device namespace but not the underlay namespace; fixed kernels should reject the operation with an authorization failure. Also confirm privileged-container policies and capability grants prevent unnecessary CAP_NET_ADMIN delegation.

Typical attack path

1. Gain local code execution in a Linux environment where CAP_NET_ADMIN is available in a network namespace, such as a privileged container or delegated network namespace.
2. Identify Geneve tunnel interfaces and determine whether the device namespace and underlay namespace differ.
3. Issue a rtnetlink changelink operation against the Geneve device using tooling or custom netlink code.
4. Abuse the missing authorization check to change Geneve tunnel attributes that are applied in the underlay namespace.
5. Cause unauthorized tunnel reconfiguration, traffic disruption, traffic redirection, or overlay-network policy bypass.

How to detect it

This issue is primarily detectable through host and network-control telemetry rather than a simple file artifact. Review Linux audit logs, kernel logs, systemd journal entries, container runtime logs, orchestration audit logs, and network-management logs for Geneve interface changes made by unexpected users, containers, or processes. Focus on rtnetlink link-change activity involving Geneve devices, especially from processes such as ip, networkctl, container entrypoints, or custom binaries running in containers or non-host network namespaces. Investigate changes to Geneve remote endpoints, VNI values, destination ports, TTL/TOS settings, device movement between namespaces, and interface down/up cycles without a corresponding approved network change. If auditd is enabled, look for NETLINK_ROUTE activity and executions of tooling used to modify links. In containerized environments, correlate suspicious activity with workloads granted CAP_NET_ADMIN or privileged mode. There are no public reports of named threat actors or ransomware campaigns exploiting this issue as of the provided data, so detection should emphasize anomalous local network-administration behavior and unauthorized Geneve tunnel modifications.

• geneve
• RTM_NEWLINK
• RTM_SETLINK
• NETLINK_ROUTE
• CAP_NET_ADMIN
• ip link set
• ip link add
• type geneve
• IFLA_INFO_KIND=geneve
• geneve_changelink
• geneve_link_config
• geneve_quiesce
• geneve_unquiesce
• /sbin/ip
• /usr/sbin/ip
• /bin/ip
• /usr/bin/ip

What your security team should do

• Prioritize patching Linux systems that use Geneve overlays, container networking, SDN, Kubernetes CNI components, virtualization networking, or privileged network namespaces.
• Inventory hosts running Geneve tunnel devices and hosts where containers or workloads receive CAP_NET_ADMIN.
• Remove CAP_NET_ADMIN from untrusted containers and workloads wherever possible; replace broad privileged-container access with narrowly scoped alternatives.
• Monitor for unexpected Geneve interface changes, rtnetlink link modifications, tunnel endpoint changes, and overlay-network instability.
• Track distribution and platform vendor advisories for the exact fixed kernel packages, then verify systems boot into the updated kernel after maintenance.
• If patching is delayed, restrict local shell access and container breakout paths on systems that combine Geneve networking with delegated network administration privileges.