Look up another CVE · open CVE-2026-63917 in the interactive tracker

CVE-2026-63917

ip6: vti: Use ip6_tnl.net in vti6_changelink().

8.8 EPSS 0.2% AV:L

Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem net/ipv6. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-63917 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	fixed	6.1.176-1	Update the kernel and reboot. Fixed in 6.1.176-1. A running kernel keeps the old code until the machine restarts.
Debian 13trixie	fixed	6.12.94-1	Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts.
Debian 14forky	fixed	7.0.12-1	Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.0.12-1	Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

ip netns add ns1 ip netns add ns2 ip -n ns1 link add vti6_test type vti6 remote ::1 local ::2 key 7 ip -n ns1 link set vti6_test netns ns2 ip -n ns2 link set vti6_test type vti6 remote ::3 local ::4 key 9 ip netns del ns2 ip netns del ns1 [ 132.495484] ------------[ cut here ]------------ [ 132.497609] kernel BUG at net/core/dev.c:12376! Commit 61220ab34948 ("vti6: Enable namespace changing") dropped NETIF_F_NETNS_LOCAL from vti6 devices. A vti6 tunnel can then move through IFLA_NET_NS_FD. After the move dev_net(dev) points at the new netns while t->net stays at the creation netns. vti6_changelink() and vti6_update() still use dev_net(dev) and dev_net(t->dev). They unlink from one per netns hash and relink into another. The creation netns is left with a stale entry. cleanup_net() of that netns later walks freed memory. Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). Cross tenant scope on container hosts.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

net/ipv6/ip6_vti.c

What this is: NETWORKING [IPSEC]MAINTAINERS section matched on net/ipv6/ip6_vti.c · netdev@vger.kernel.org · Maintained
Kernel module: ip6_vti

Check it on the machine

grep -w CONFIG_IPV6_VTI /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w ip6_vti

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.

bookworm, trixie, forky, sidm

m: a loadable module on every flavour - check lsmod, can be blacklisted

Build switch: CONFIG_IPV6_VTI

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-07-19 (3 months ago)source
CVSS: 8.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:Hsource recompute it
Attack vector: local (AV:L)source
EPSS: 0.17%, higher than 5.8% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: not yet assignedsource
Subsystem: net/ipv6

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
3.15	5.10.259	0cdce7618464
3.15	5.15.210	f5c68875e25f
3.15	6.1.176	d9c5eecdb3c7
3.15	6.6.143	f1e89a943ee5
3.15	6.12.93	225b467e3b63
3.15	6.18.35	fc32be9ac278
3.15	7.0.12	ee1778ba0f5c
3.15	7.1	11b326fb0a37

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local: The bug is reached only through rtnetlink configuration (RTM_NEWLINK changelink and RTM_SETLINK netns move via `ip link`), not through remote packet handling on the vti6 tunnel itself.
AC:LAttack complexity, low: Exploitation is a deterministic, attacker-controlled sequence (create vti6, move netns, changelink, delete netns) with no races or external victim state required.
PR:LPrivileges required, low: The fix commit and rtnetlink path confirm reachability with CAP_NET_ADMIN inside an unprivileged user+network namespace (`unshare --user --map-root-user --net`), not init-namespace root.
UI:NUser interaction, none: No victim interaction is required; the attacker triggers the bug entirely through their own netlink operations.
S:CScope, changed: On container hosts, an unprivileged tenant can corrupt namespace teardown and panic the host kernel, impacting resources outside the attacker's security scope (other tenants and the host).
C:HConfidentiality impact, high: The stale per-netns hash leaves `cleanup_net()`/`vti6_exit_rtnl_net()` walking freed `ip6_tnl` list nodes, constituting a use-after-free with arbitrary kernel memory read potential.
I:HIntegrity impact, high: Cross-netns hash corruption can leave dangling pointers and drive `unregister_netdevice_queue()` on already-freed devices (kernel BUG at net/core/dev.c:12376), enabling memory corruption exploitable for control-flow hijacking.
A:HAvailability impact, high: The published reproducer reliably triggers a kernel BUG during namespace cleanup, causing host-wide denial of service via kernel panic/oops.