CVE-2026-63917: Linux Kernel Privilege Escalation Flaw

CVE-2026-63917 Overview

CVE-2026-63917 is a Linux kernel vulnerability in the IPv6 Virtual Tunnel Interface (vti6) driver. The flaw resides in vti6_changelink() and vti6_update(), which incorrectly reference dev_net(dev) after a tunnel device is moved between network namespaces. A stale hash entry is left in the original creation namespace, and cleanup_net() later walks freed memory, triggering kernel BUG at net/core/dev.c:12376. The regression was introduced by commit 61220ab34948 ("vti6: Enable namespace changing"), which removed NETIF_F_NETNS_LOCAL from vti6 devices. The condition is reachable from an unprivileged user namespace, giving it cross-tenant scope on multi-tenant container hosts.

Critical Impact
An unprivileged local user with CLONE_NEWUSER and CLONE_NEWNET capabilities can trigger kernel memory corruption, enabling denial of service and potential local privilege escalation on container hosts.

Affected Products

Linux kernel versions containing commit 61220ab34948 ("vti6: Enable namespace changing") without the fix
Container host platforms using unprivileged user namespaces (Kubernetes, Docker, LXC)
Distributions shipping the affected upstream Linux kernel prior to the referenced stable backports

Discovery Timeline

2026-07-19 - CVE-2026-63917 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-63917

Vulnerability Analysis

The vulnerability is a use-after-free triggered by inconsistent network namespace tracking in the vti6 tunnel driver. A vti6 device stores its creation namespace pointer in t->net while dev_net(dev) reflects the device's current namespace. After moving the device via IFLA_NET_NS_FD, these two pointers diverge.

When vti6_changelink() runs on the moved device, it uses dev_net(dev) to unlink the tunnel from a per-namespace hash and relink it into another. The lookup targets the new namespace instead of the creation namespace where the entry actually lives. The original namespace retains a dangling hash entry pointing to the tunnel structure.

When the creation namespace is destroyed, cleanup_net() iterates the stale hash and dereferences freed memory, producing a kernel BUG() at net/core/dev.c:12376. Under crafted conditions, this behavior can be steered toward controlled memory rather than a hard panic.

Root Cause

Commit 61220ab34948 removed the NETIF_F_NETNS_LOCAL flag from vti6 devices, permitting movement between namespaces. However, vti6_changelink() and vti6_update() were not updated to consult ip6_tnl.net (the creation namespace) for hash operations. The mismatch between dev_net(dev) and t->net breaks the invariant that hash link and unlink target the same namespace bucket [CWE-416].

Attack Vector

Exploitation requires local access but no elevated privileges on the host. An attacker inside an unprivileged user namespace executes unshare --user --map-root-user --net, creates a vti6 tunnel, moves it to a second namespace with ip link set ... netns, invokes ip link set ... type vti6 ... to trigger vti6_changelink(), and then destroys the namespaces. The reproduction sequence in the upstream report uses standard iproute2 commands and requires no custom tooling. See the upstream kernel commit for the corrected logic that replaces dev_net(dev) with ip6_tnl.net inside these functions.

Detection Methods for CVE-2026-63917

Indicators of Compromise

Kernel oops or panic messages referencing kernel BUG at net/core/dev.c:12376 with cleanup_net in the backtrace
Presence of vti6_changelink or vti6_update symbols in kernel crash stack traces
Unexpected process invocations of unshare --user --map-root-user --net followed by ip link add ... type vti6 from non-privileged accounts

Detection Strategies

Audit /var/log/kern.log, dmesg, and journalctl -k for BUG: entries involving net/core/dev.c or cleanup_net
Enable Linux Auditd rules covering unshare, setns, and ip invocations against AF_NETLINK from unprivileged UIDs
Correlate namespace creation and deletion events with subsequent kernel warnings within a short time window

Monitoring Recommendations

Aggregate kernel ring buffer contents from container hosts into a centralized log platform for anomaly detection
Alert on repeated user-namespace creation from workloads that historically do not exercise CLONE_NEWUSER
Track ip6_vti module load events and RTM_NEWLINK netlink messages targeting vti6 link types

How to Mitigate CVE-2026-63917

Immediate Actions Required

Apply the upstream stable kernel updates referenced in the fix commits and reboot affected hosts
Disable unprivileged user namespaces on hosts that do not require them by setting kernel.unprivileged_userns_clone=0 (Debian/Ubuntu) or user.max_user_namespaces=0 (RHEL family)
Unload or blacklist the ip6_vti kernel module on systems that do not use IPv6 VTI tunnels

Patch Information

The fix replaces dev_net(dev) with ip6_tnl.net inside vti6_changelink() and vti6_update(), ensuring the tunnel is unlinked and relinked in its creation namespace regardless of the device's current namespace. The stable backports are available in commits 0cdce76, 11b326f, 225b467, d9c5eed, ee1778b, f1e89a9, f5c6887, and fc32be9 on git.kernel.org.

Workarounds

Blacklist the ip6_vti module: add blacklist ip6_vti to /etc/modprobe.d/blacklist-vti6.conf
Restrict user namespace creation to trusted UIDs through seccomp or LSM policies (AppArmor, SELinux)
For container runtimes, drop CAP_NET_ADMIN from workload capability sets and enforce a seccomp profile that blocks the unshare and setns syscalls where feasible

bash

# Configuration example: disable unprivileged user namespaces and blacklist vti6
echo 'kernel.unprivileged_userns_clone=0' | sudo tee /etc/sysctl.d/99-cve-2026-63917.conf
echo 'user.max_user_namespaces=0' | sudo tee -a /etc/sysctl.d/99-cve-2026-63917.conf
sudo sysctl --system

echo 'blacklist ip6_vti' | sudo tee /etc/modprobe.d/blacklist-vti6.conf
sudo rmmod ip6_vti 2>/dev/null || true