CVE-2026-63921 Overview
CVE-2026-63921 is a Linux kernel vulnerability in the IPv6 Virtual Tunnel Interface (VTI) subsystem. The flaw exists in vti6_siocdevprivate(), which uses dev_net(dev) instead of t->net when resolving tunnel collisions during SIOCCHGTUNNEL operations. After a tunnel is moved between network namespaces via IFLA_NET_NS_FD, this mismatch allows an attacker to hijack tunnel entries in the creation netns hash bucket. The issue is reachable from an unprivileged user namespace using unshare --user --map-root-user --net, giving it cross-tenant scope on container hosts. The Linux kernel maintainers have released patches across multiple stable branches.
Critical Impact
An unprivileged local user can hijack VTI6 tunnel routing across network namespaces, redirecting decrypted xfrm traffic through an attacker-controlled device on multi-tenant container hosts.
Affected Products
- Linux kernel — IPv6 VTI (net/ipv6/ip6_vti.c) subsystem
- Multi-tenant container hosts exposing user namespaces to unprivileged users
- Stable kernel branches referenced in the upstream fix commits
Discovery Timeline
- 2026-07-19 - CVE-2026-63921 published to the National Vulnerability Database
- 2026-07-20 - Last updated in NVD database
Technical Details for CVE-2026-63921
Vulnerability Analysis
The vulnerability is a network namespace confusion flaw in the Linux kernel's vti6_siocdevprivate() handler. When a VTI6 tunnel device is migrated across network namespaces through IFLA_NET_NS_FD, the device's dev_net(dev) reflects the new namespace while the tunnel's internal t->net still references the creation namespace. The SIOCCHGTUNNEL code path performs its collision lookup in dev_net(dev), but vti6_update() mutates the hash bucket associated with t->net. This inconsistency lets an attacker force vti6_update() to prepend a migrated tunnel at the head of a hash bucket in a foreign network namespace. Subsequent lookups in the creation netns then resolve to the migrated device controlled by the attacker, and xfrm receive processing delivers matched packets through that device.
Root Cause
The root cause is inconsistent use of network namespace references between the lookup and update paths. vti6_siocdevprivate() uses dev_net(dev) for vti6_locate() while vti6_update() operates on t->net. Additionally, the CAP_NET_ADMIN capability check at the top of the case validates against dev_net(dev)->user_ns, which after migration is the attacker-controlled namespace rather than the creation namespace.
Attack Vector
An unprivileged local user creates a user and network namespace via unshare --user --map-root-user --net, migrates a VTI6 tunnel into their namespace, and issues SIOCCHGTUNNEL with parameters that match a tunnel in the original creation namespace. Because the lookup misses in dev_net(dev), vti6_update() inserts the attacker's device into the creation namespace's hash bucket. Cross-tenant workloads on the same host that later match those tunnel parameters have their xfrm-decrypted packets routed through the attacker's device. No specific exploitation code is published in the referenced advisory; consult the upstream commits such as 1acfb7d9c6fc and df42ac708acc for the exact code paths.
Detection Methods for CVE-2026-63921
Indicators of Compromise
- Unexpected creation of user and network namespaces by unprivileged processes, particularly invocations of unshare --user --map-root-user --net.
- SIOCCHGTUNNEL and IFLA_NET_NS_FD operations issued against VTI6 devices from non-root user namespaces.
- New or renamed ip6_vti* devices appearing in netns hash buckets that do not correspond to legitimate administrator activity.
- Unexpected xfrm packet delivery through tunnel devices with a different owning netns than expected.
Detection Strategies
- Audit ioctl syscalls targeting SIOCCHGTUNNEL (0x89f3) and correlate them with the caller's user namespace and effective UID.
- Monitor kernel audit logs for netlinkRTM_NEWLINK messages carrying the IFLA_NET_NS_FD attribute on VTI6 devices.
- Track process invocations of unshare with --user, --net, or --map-root-user flags on multi-tenant hosts.
Monitoring Recommendations
- Enable eBPF-based syscall telemetry to record namespace transitions and tunnel ioctl activity per process.
- Baseline legitimate VTI6 tunnel administration and alert on tunnel creation, migration, or modification by unprivileged users.
- Forward kernel audit events and container runtime logs to a centralized data lake for cross-tenant correlation.
How to Mitigate CVE-2026-63921
Immediate Actions Required
- Apply the upstream kernel patches referenced in the advisory to all affected stable branches on container hosts and multi-tenant systems.
- Restrict unprivileged user namespace creation by setting kernel.unprivileged_userns_clone=0 on distributions that expose the sysctl.
- Audit workloads that rely on VTI6 tunnels and confirm they run in namespaces controlled by trusted administrators only.
- Disable the ip6_vti kernel module on hosts that do not require IPv6 VTI functionality.
Patch Information
The fix switches the SIOCCHGTUNNEL path on a non-fallback device to use t->net for the lookup so it matches the netns vti6_update() operates on. It also adds ns_capable(self->net->user_ns, CAP_NET_ADMIN) before the lookup to require CAP_NET_ADMIN in the creation netns as well. SIOCADDTUNNEL and SIOCCHGTUNNEL on the fallback device continue to use dev_net(dev), which equals init_net there. Patches are available in the following upstream commits: 1acfb7d9c6fc, 44d2ff7d2178, 596f6354c96a, 853f6ea482df, 8b484efd5cb4, 94ff740a7f9e, d2236348414b, and df42ac708acc.
Workarounds
- Set kernel.unprivileged_userns_clone=0 or use user.max_user_namespaces=0 to block unprivileged namespace creation until the patch is applied.
- Blacklist the ip6_vti module on systems that do not require IPv6 VTI tunnels.
- Apply seccomp or AppArmor profiles to container workloads to deny unshare, CLONE_NEWUSER, and CLONE_NEWNET operations.
# Configuration example - restrict unprivileged namespace and disable ip6_vti
sysctl -w kernel.unprivileged_userns_clone=0
sysctl -w user.max_user_namespaces=0
echo 'install ip6_vti /bin/true' > /etc/modprobe.d/disable-ip6_vti.conf
rmmod ip6_vti 2>/dev/null || true
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

