CVE-2026-63921

What it actually does

This Linux kernel flaw affects IPv6 VTI tunnel handling across network namespaces. A migrated vti6 tunnel can be modified using SIOCCHGTUNNEL while the kernel performs collision checks in the wrong network namespace. Because the lookup uses dev_net(dev) instead of the tunnel’s original net namespace, an unprivileged user with control of a user and network namespace can cause the migrated tunnel to be inserted into the hash table of the creation namespace with attacker-chosen parameters. Subsequent lookups in the original namespace may resolve to the attacker-controlled migrated device, allowing cross-namespace traffic interception or manipulation through xfrm receive paths. The issue is reachable from unprivileged user namespaces and can cross container or tenant boundaries on shared Linux hosts.

Why it matters to the business

On multi-tenant Linux systems, container hosts, CI runners, Kubernetes nodes, or platforms that allow unprivileged user namespaces, this vulnerability can let a low-privileged local user influence networking outside their intended namespace. The practical risk is unauthorized access to traffic, disruption or redirection of IPv6 tunnel traffic, and potential escalation from a contained workload into host- or peer-tenant-impacting behavior. It is not currently listed in CISA KEV, has low EPSS, and has no reported public exploit maturity in the provided data, but the CVSS impact is high because successful exploitation can affect confidentiality, integrity, and availability across security boundaries.

How an attack unfolds

An attacker first obtains low-privileged local code execution on a Linux host where unprivileged user namespaces and network namespaces are available. They create their own user and network namespace, obtain CAP_NET_ADMIN inside that namespace, and create or manipulate an IPv6 VTI tunnel. The attacker then migrates the tunnel between namespaces using network namespace file-descriptor based movement. After migration, they issue a tunnel change operation through the private tunnel ioctl path. Due to the namespace mismatch, the kernel checks for tunnel parameter collisions in the attacker-controlled migrated namespace while updating hash state in the tunnel’s original namespace. By choosing parameters that match a tunnel in the original namespace, the attacker can cause future lookups there to select the attacker-controlled migrated device. Matched xfrm/IPsec-related receive traffic may then be delivered through the attacker-controlled device, enabling cross-namespace traffic redirection, exposure, or disruption.

How to fix it

Apply the vendor-supplied Linux kernel update that includes the fix for the IPv6 VTI namespace lookup and authorization logic. The corrected behavior uses the tunnel’s stored network namespace for SIOCCHGTUNNEL collision checks and requires CAP_NET_ADMIN in the creation namespace user namespace before allowing the update. No exact fixed package versions were provided, so operators should consult their Linux distribution, appliance, cloud image, or kernel vendor advisory for the patched kernel version corresponding to CVE-2026-63921. Where immediate patching is not possible, reduce exposure by disabling unprivileged user namespaces where operationally feasible, restricting creation and migration of network namespaces, limiting CAP_NET_ADMIN in containers, avoiding privileged or overly-capable containers, disabling or preventing autoload of unused IPv6 VTI/IPsec tunnel modules, and isolating multi-tenant workloads onto patched hosts.

How to confirm the fix worked

Confirm that systems are running a kernel build from the relevant vendor that contains the vti6_siocdevprivate fix. For source-based validation, verify that the SIOCCHGTUNNEL path for non-fallback IPv6 VTI devices performs lookup against the tunnel’s stored namespace rather than dev_net(dev), and that it performs an ns_capable check against the creation namespace user_ns. For runtime validation, verify that an unprivileged user namespace cannot change a migrated vti6 tunnel in a way that affects the original namespace. Security teams should also inventory hosts with unprivileged user namespaces enabled, IPv6 VTI/IPsec usage, container workloads with CAP_NET_ADMIN, and kernels older than the vendor-fixed release.

Typical attack path

1. Gain low-privileged local execution on a Linux system with unprivileged user namespaces enabled.
2. Create a user namespace and network namespace, for example using unshare-style functionality, and obtain CAP_NET_ADMIN inside the attacker-controlled namespace.
3. Create or access an IPv6 VTI tunnel device and move it across network namespaces using netlink namespace migration semantics such as IFLA_NET_NS_FD.
4. Invoke the IPv6 tunnel private ioctl path, specifically a tunnel change operation, against the migrated device.
5. Choose tunnel parameters that collide with a tunnel in the original creation namespace while avoiding detection in the migrated namespace lookup.
6. Trigger kernel state where the original namespace hash bucket resolves to the attacker-controlled migrated tunnel device.
7. Receive, redirect, observe, or disrupt traffic that should have been associated with the legitimate tunnel in the original namespace.

How to detect it

There is unlikely to be a single definitive log entry proving exploitation because the vulnerable behavior occurs inside kernel namespace and tunnel bookkeeping. Focus detection on suspicious prerequisites and exploitation behaviors: unprivileged creation of user and network namespaces, creation or movement of IPv6 VTI tunnel devices, SIOCCHGTUNNEL ioctl use, CAP_NET_ADMIN activity inside containers, and unexpected xfrm/IPsec receive behavior. Useful sources include Linux auditd syscall logs, eBPF-based syscall and netlink telemetry, container runtime logs, Kubernetes audit logs, shell history where available, process execution telemetry, and network device inventory snapshots. Look for non-root or container-originated processes invoking unshare, iproute2 tunnel commands, ioctl request 0x89f3, or netlink operations involving IFLA_NET_NS_FD. Also investigate unexplained IPv6 VTI devices, changed tunnel parameters, xfrm policy/state anomalies, and traffic that appears to traverse the wrong namespace or interface.

• SIOCCHGTUNNEL
• SIOCADDTUNNEL
• SIOCDELTUNNEL
• SIOCGETTUNNEL
• ioctl request=0x89f3
• a1=89f3
• IFLA_NET_NS_FD
• unshare --user --map-root-user --net
• ip -6 tunnel add
• ip -6 tunnel change
• ip -6 tunnel del
• ip link set netns
• ip6_vti
• vti6
• vti6_siocdevprivate
• vti6_update
• xfrm

What your security team should do

• Prioritize patching shared Linux infrastructure, container hosts, Kubernetes nodes, CI/CD runners, and systems that permit unprivileged user namespaces.
• Temporarily disable unprivileged user namespaces on systems that do not require them, after application compatibility testing.
• Remove CAP_NET_ADMIN from containers and workloads unless strictly required.
• Audit privileged containers, host-networked containers, and workloads that can create or move network namespaces.
• Disable or block loading of unused IPv6 VTI tunnel functionality where it is not required.
• Add audit monitoring for tunnel ioctl operations, namespace creation, and network namespace migration by non-administrative users.
• Review recent activity for suspicious creation or modification of vti6/ip6_vti tunnel devices, especially from containerized processes.
• Segment or evacuate sensitive multi-tenant workloads from unpatched hosts until remediation is complete.