CVE-2026-63829

What it actually does

This is a Linux kernel authorization bypass in the GRE and ERSPAN tunnel change-link path. The vulnerable rtnetlink RTM_NEWLINK handling verifies CAP_NET_ADMIN only in the network namespace that owns the tunnel device, but not in the tunnel’s linked network namespace when those namespaces differ. A local attacker who has CAP_NET_ADMIN in one relevant network namespace, but not the tunnel link namespace, can modify live GRE/ERSPAN tunnel configuration they should not control. Depending on tunnel use, this can affect confidentiality, integrity, and availability by changing tunnel endpoints, metadata collection settings, routing-related tunnel parameters, or causing tunnel disruption.

Why it matters to the business

Systems that use Linux network namespaces, containers, virtual networking, GRE tunnels, or ERSPAN monitoring tunnels may allow a locally privileged namespace user to tamper with network paths outside their intended administrative boundary. In practical terms, this could enable traffic interception, monitoring disruption, tunnel misrouting, or outage of overlay and monitoring networks. The issue is high severity but currently has low EPSS, no known public exploit maturity, and is not listed in CISA KEV, so remediation should be prioritized for multi-tenant Linux hosts, container platforms, network appliances, and systems relying on GRE/ERSPAN isolation.

How an attack unfolds

An attacker first needs local execution and enough privilege to hold CAP_NET_ADMIN in a network namespace that owns or can operate on the visible tunnel device. The attacker then targets a GRE or ERSPAN tunnel where the tunnel link namespace differs from the device namespace. By sending a crafted rtnetlink RTM_NEWLINK change request, such as through the iproute2 tooling or a custom netlink client, the attacker reaches ipgre_changelink() or erspan_changelink(). On vulnerable kernels, the kernel checks administrative capability only against dev_net(dev) and fails to require CAP_NET_ADMIN in the tunnel link namespace before parsing attributes and updating live tunnel fields. The attacker can therefore rewrite tunnel configuration despite lacking authority in the link namespace. Successful exploitation can redirect or disrupt encapsulated traffic, alter tunnel metadata behavior, or undermine network monitoring paths.

How to fix it

Upgrade to a Linux kernel or vendor kernel package that includes the fix for requiring CAP_NET_ADMIN in the tunnel link namespace for ip_gre and ERSPAN changelink operations. Because exact fixed package versions were not provided, use the fixed kernel version or backported advisory from the relevant Linux distribution, cloud image provider, appliance vendor, or container host platform. Where immediate patching is not possible, reduce exposure by limiting CAP_NET_ADMIN grants in containers and user-controlled namespaces, avoiding privileged containers, disabling unneeded GRE/ERSPAN tunnel functionality, restricting local shell access to systems that manage tunnels, and enforcing runtime/container policies that prevent untrusted workloads from creating or modifying network links. Reboot into the patched kernel after installation unless live patching is explicitly supported and confirmed for this fix.

How to confirm the fix worked

Confirm the running kernel includes the upstream or vendor backport for the change that gates ipgre_changelink() and erspan_changelink() with a CAP_NET_ADMIN check in the tunnel link namespace. Validate using vendor package metadata, kernel changelogs, or source inspection for the added rtnl_dev_link_net_capable() enforcement in the GRE/ERSPAN changelink path. Operationally, verify that untrusted containers or namespaces do not retain CAP_NET_ADMIN unless required. In a controlled non-production test, attempt to modify a GRE or ERSPAN tunnel from a namespace that has CAP_NET_ADMIN in the device namespace but not in the tunnel link namespace; patched kernels should reject the change with a permission error rather than applying tunnel attribute updates.

Typical attack path

1. Obtain local code execution on a Linux system where network namespaces and GRE or ERSPAN tunnels are used.
2. Acquire or already possess CAP_NET_ADMIN in one network namespace, such as inside a privileged or semi-privileged container/network namespace.
3. Identify a GRE or ERSPAN tunnel device whose device namespace and tunnel link namespace differ.
4. Send an RTM_NEWLINK request to modify the tunnel using iproute2 or a custom NETLINK_ROUTE client.
5. Abuse the missing CAP_NET_ADMIN check in the tunnel link namespace to change tunnel parameters without proper authorization.
6. Redirect, observe, alter, or disrupt tunnel-carried traffic or monitoring flows depending on the tunnel’s role.

How to detect it

There is no single reliable network IOC for this vulnerability because exploitation occurs through local kernel netlink operations and may look like legitimate tunnel administration. Hunt for unauthorized GRE or ERSPAN configuration changes, especially from containerized processes, non-host namespaces, automation accounts, or users that should not administer host networking. Useful sources include Linux auditd logs for NETLINK_ROUTE/socket sendmsg activity, process execution logs for iproute2 commands, shell history, EDR telemetry, container runtime audit logs, orchestration audit logs, and configuration management drift records. Review timestamps of tunnel parameter changes against change tickets and user sessions. Look for RTM_NEWLINK operations affecting GRE/ERSPAN devices, unexpected changes to tunnel local/remote endpoints, keys, metadata collection mode, TTL/TOS, link namespace relationships, or sudden tunnel interface flaps. Also investigate unexplained packet loss, monitoring blind spots, ERSPAN collector changes, or GRE route changes following local activity by namespace-confined users.

• RTM_NEWLINK
• NETLINK_ROUTE
• ip link set
• ip tunnel change
• ip link set type gre
• ip link set type erspan
• ipgre
• erspan
• gre0
• gretap0
• erspan0
• IFLA_GRE_COLLECT_METADATA
• collect_md
• CAP_NET_ADMIN
• Operation not permitted

What your security team should do

• Prioritize patching Linux hosts that run containers, network namespaces, virtual networking stacks, GRE tunnels, ERSPAN monitoring, SDN components, or network appliances.
• Inventory systems where untrusted or semi-trusted workloads are granted CAP_NET_ADMIN, especially privileged containers and orchestration nodes.
• Remove CAP_NET_ADMIN from workloads that do not strictly require it and block privileged containers by default.
• Review GRE and ERSPAN tunnel usage and restrict tunnel administration to trusted host-level operators only.
• Monitor rtnetlink RTM_NEWLINK activity involving GRE and ERSPAN devices from containerized or namespace-confined processes.
• If patching must be delayed, isolate affected hosts, disable unnecessary tunnel modules or tunnel configurations, and increase auditing around network link changes.
• Track distribution and vendor advisories for exact fixed kernel package versions and ensure systems reboot into the fixed kernel.