CVE-2026-63917

What it actually does

This is a Linux kernel use-after-free in IPv6 VTI tunnel handling during network namespace moves. A vti6 device can be created in one network namespace, moved to another, and then reconfigured so that kernel bookkeeping uses the device's current namespace while the tunnel object still references its original namespace. This can leave a stale per-namespace hash entry behind; when the original namespace is later cleaned up, the kernel may walk freed memory and trigger memory corruption or a kernel BUG. Because the issue is reachable from an unprivileged user namespace with a mapped root user and a network namespace, it can be abused by low-privileged local users or container workloads where unprivileged user namespaces are enabled. The practical impact is local denial of service through kernel crash, with potential for privilege escalation depending on kernel configuration, allocator behavior, and exploit development.

Why it matters to the business

Systems that allow untrusted local users or containers to create user and network namespaces are most exposed. Successful exploitation can crash the host kernel, disrupting all workloads on that host, including unrelated containers or tenants. In container-hosting and multi-tenant environments, the cross-namespace nature of the bug makes the operational risk higher because one low-privileged workload may be able to affect the availability and potentially the security boundary of the host. Although EPSS is currently low and there is no known KEV listing, the vulnerability is recent and has a clear reproducer pattern, so internet-facing container platforms, CI runners, developer sandboxes, and shared compute nodes should treat remediation as a priority.

How an attack unfolds

An attacker first obtains low-privileged local code execution, such as a shell inside a container, CI job, or user account on a Linux host. If unprivileged user namespaces are enabled, the attacker creates a new user namespace with root mapped inside it and a new network namespace. Within that namespace, the attacker creates an IPv6 VTI tunnel device, moves the device into another network namespace, and reconfigures the tunnel parameters. This causes the device and tunnel object to disagree about which namespace owns the tunnel hash entries. The attacker then deletes or exits the namespaces in an order that forces namespace cleanup to traverse the stale entry. The kernel subsequently accesses freed memory, typically causing an oops or BUG and crashing the host. With additional kernel exploitation work, the same memory corruption condition could potentially be shaped toward privilege escalation, but the immediately demonstrated impact is host-level denial of service.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the vti6 namespace handling fix. If exact fixed package versions are not yet available from the vendor, track the vendor advisory for CVE-2026-63917 and deploy the first kernel build that includes the upstream change to use the tunnel object's stored network namespace in vti6_changelink() and related update paths. Reboot into the fixed kernel after installation; merely installing the package is not sufficient if the vulnerable kernel remains running. As interim mitigations, disable unprivileged user namespaces where operationally feasible, restrict creation of network namespaces by untrusted users, avoid granting CAP_NET_ADMIN to containers, block or tightly control privileged containers, and restrict loading or use of IPv6 VTI tunneling support if it is not required. On container platforms, enforce seccomp, AppArmor/SELinux, and runtime policies that prevent namespace manipulation and tunnel device creation by untrusted workloads.

How to confirm the fix worked

Confirm the running kernel version, not just the installed package version, after remediation. Verify that the active kernel contains the vendor fix for the IPv6 VTI namespace-move bug. On Linux, compare `uname -r` with the fixed kernel package and confirm the system has been rebooted into the patched kernel. Review vendor changelogs or package metadata for references to CVE-2026-63917, vti6, ip6 tunnel namespace handling, or `vti6_changelink()`. Validate exposure by checking whether unprivileged user namespaces are enabled and whether untrusted users or containers can create network namespaces and vti6 tunnel devices. Where safe and authorized, use a non-production test system to verify that the public reproducer pattern no longer triggers a kernel BUG during vti6 namespace moves and cleanup.

Typical attack path

1. Gain low-privileged local execution on a Linux system, container host, CI runner, or shared shell environment.
2. Create an unprivileged user namespace and map root inside it, commonly using unshare-style functionality.
3. Create one or more network namespaces under attacker control.
4. Create an IPv6 VTI tunnel device of type vti6 with chosen local, remote, and key parameters.
5. Move the vti6 device between network namespaces using netlink namespace-move functionality.
6. Reconfigure the moved vti6 tunnel so kernel tunnel bookkeeping is updated against the wrong namespace context.
7. Delete or exit the involved network namespaces to trigger cleanup of stale tunnel hash entries.
8. Cause the kernel to dereference freed memory, leading to a kernel BUG, oops, crash, or potentially exploitable memory corruption.

How to detect it

Look for evidence of prior kernel crashes or attempts to create and move IPv6 VTI devices between network namespaces. Primary log sources include `dmesg`, journald kernel logs, `/var/log/kern.log`, `/var/log/messages`, crash dump metadata, auditd process execution logs, EDR process telemetry, container runtime logs, and Kubernetes node logs where applicable. Search for kernel BUG, oops, panic, KASAN, slab, or use-after-free messages near references to vti6, IPv6 tunnel handling, network namespace cleanup, `cleanup_net`, `vti6_changelink`, or `net/core/dev.c`. Process telemetry should be reviewed for suspicious use of `unshare` followed by `ip netns`, `ip link add ... type vti6`, `ip link set ... netns`, and subsequent namespace deletion. Because many legitimate administrators use `ip` and network namespaces, correlate command sequences, user context, container identity, timing, and any immediate host instability. If crash dumps are available, inspect call traces for vti6, ip6 tunnel, network device unregister, or namespace cleanup functions. Absence of logs does not prove absence of exploitation, especially if the host crashed before logs were flushed.

• kernel BUG at net/core/dev.c:12376
• vti6_changelink
• vti6_update
• cleanup_net
• type vti6
• ip link add vti6
• ip link set vti6
• ip netns add
• ip netns del
• unshare --user --map-root-user --net
• IFLA_NET_NS_FD
• BUG: kernel NULL pointer dereference
• BUG: unable to handle kernel paging request
• KASAN: use-after-free
• general protection fault
• kernel panic
• vti6_test
• link add vti6_test type vti6
• link set vti6_test netns

What your security team should do

• Prioritize patching shared Linux hosts, container hosts, Kubernetes nodes, CI/CD runners, developer sandboxes, and systems that allow untrusted local code execution.
• Inventory systems with unprivileged user namespaces enabled and treat them as higher risk until patched.
• Reboot systems after kernel updates and verify the running kernel is the fixed version.
• Temporarily disable unprivileged user namespaces on high-risk systems if business operations allow.
• Remove CAP_NET_ADMIN from containers and workloads that do not explicitly require it.
• Block privileged containers and restrict host namespace sharing for untrusted workloads.
• Monitor kernel logs for BUG, oops, panic, or use-after-free messages involving vti6, IPv6 tunnels, network namespace cleanup, or `net/core/dev.c`.
• Add detections for suspicious local execution of `unshare` and `ip link` commands that create or move `vti6` devices between network namespaces.
• If crashes have occurred, preserve kernel logs, vmcores, audit logs, container runtime logs, and recent process execution telemetry before rebooting or redeploying nodes.
• Track vendor advisories because exploit maturity can change quickly for local kernel namespace bugs with compact reproducer steps.