Look up another CVE · open CVE-2026-89563 in the interactive tracker
CVE-2026-89563
ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit()
Published 2026-09-11 (37 days 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-89563 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 | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
ip6_tnl_xmit() may need to expand headroom before it can push the outer IPv6 and optional encap headers. It currently does that with skb_realloc_headroom(), copies skb->sk ownership, consumes the original skb, and then continues processing with the replacement skb kept only in its local variable. That is safe only if the helper cannot fail afterwards. But this helper still has post-reallocation error exits. collect_md tunnels reject non-NONE encap after the replacement, and ip6_tnl_encap() can also fail later. In those cases the helper returns an error to its callers while the caller still only has the original skb pointer. Both ip6_tnl_start_xmit() and the IPv6 GRE paths free the caller skb on error, so they can end up freeing an skb that ip6_tnl_xmit() already consumed. Use skb_cow_head() instead. It provides the required headroom and writability without privately replacing the caller-owned skb, so later error returns cannot leave callers with a stale pointer. The Ethernet users, ip6gretap and ip6erspan, clear IFF_TX_SKB_SHARING and already call skb_cow_head() before entering ip6_tnl_xmit(). They do not rely on the removed skb_shared() reallocation. This also makes the IPv6 tunnel path consistent with ip_tunnel_xmit().
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_tunnel.c
- What this is
- NETWORKING [IPv4/IPv6]MAINTAINERS section matched on net/ipv6/ip* · netdev@vger.kernel.org · Maintained
- Kernel module
- ip6_tunnel
Check it on the machine
grep -w CONFIG_IPV6_TUNNEL /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_tunnelPrints 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, sid, bookworm · linux-6.12m
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switch
- CONFIG_IPV6_TUNNEL
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
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.14%, higher than 2.9% 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 |
|---|---|---|
| 4.7 | 5.10.270 | 6e8eff8ed13b |
| 4.7 | 5.15.221 | dc1a319a4815 |
| 4.7 | 6.1.188 | 629d5557e635 |
| 4.7 | 6.6.157 | defa0adeff13 |
| 4.7 | 6.12.109 | 37df5bc6b5cc |
| 4.7 | 6.18.50 | b36dfd6e8cff |
| 4.7 | 7.2.4 | 8fc56ca49fc0 |
| 4.7 | 7.3 | 87f21b59ddc6 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
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 double-free is in ip6_tnl_xmit() on the ip6tnl/ip6gre transmit path. The reliable trigger is local: create a collect-metadata tunnel with FOU/GUE encap via rtnetlink, then push a packet through ip6_tnl_start_xmit() with tc tunnel_key+mirred. Ordinary remote packets on a working ip6tnl do not hit the post-realloc error path.
- AC:LAttack complexity, low
- Once the collect-md device is created with non-NONE encap, any skb that needs headroom expansion takes skb_realloc_headroom(), consume_skb()s the original, then deterministically fails the collect_md/encap check so the caller kfree_skb()s the stale pointer. The published PoC reproduces this without a race or lucky layout.
- PR:LPrivileges required, low
- Creating ip6tnl/ip6gre and tc filters needs CAP_NET_ADMIN, which an unprivileged user gets in their own user and network namespaces (unshare -Urn). The reporter confirmed this userns path; the resulting skb double-free is not confined to that namespace.
- UI:NUser interaction, none
- The attacker creates the tunnel, installs the tc redirect, and generates the packet themselves. No other user must mount a filesystem, open a file, or otherwise interact.
- S:UScope, unchanged
- The skb double-free corrupts kernel heap (skbuff_head_cache) on the same host. This is standard in-kernel memory corruption, not a VM escape, IOMMU/DMA bypass, or other cross-authority impact.
- C:HConfidentiality impact, high
- consume_skb() frees the original skb and the caller later kfree_skb()s that stale pointer, a slab use-after-free/double-free. Reclaiming the skbuff_head_cache object yields an arbitrary kernel read primitive, so confidentiality impact is High.
- I:HIntegrity impact, high
- The same skb double-free/UAF is a heap primitive: the freed sk_buff can be sprayed and the second free or a later dereference used for an arbitrary write or control-flow hijack, so integrity impact is High.
- A:HAvailability impact, high
- KASAN reports slab-use-after-free in ip6_tnl_start_xmit()/kfree_skb and the reproducer panics the kernel. Any skb double-free can oops or panic even if not fully exploited, so availability impact is High.