Look up another CVE · open CVE-2026-89562 in the interactive tracker
CVE-2026-89562
ip6_gre: fix hardware header length for NBMA tunnels
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-89562 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
ip6gre_tnl_link_config_route() accumulates the lower device's hardware header length into dev->hard_header_len whenever header_ops is set. This is incorrect for both users of header_ops. ip6gretap and ip6erspan have a fixed Ethernet hardware header length. For an NBMA ip6gre tunnel, ip6gre_header() creates only the GRE header, the optional FOU or GUE header, and the outer IPv6 header. The lower device header is headroom needed later, not part of the tunnel device's hardware header. Keep the lower device header in needed_headroom. Set hard_header_len to the tunnel header length only for ARPHRD_IP6GRE devices with header_ops, and leave the fixed Ethernet header length unchanged for tap and erspan devices.
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_gre.c
- What this is
- NETWORKING [IPv4/IPv6]MAINTAINERS section matched on net/ipv6/ip* · netdev@vger.kernel.org · Maintained
- Kernel module
- ip6_gre
Check it on the machine
grep -w CONFIG_IPV6_GRE /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_grePrints 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_GRE
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.13%, higher than 2.3% 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 |
|---|---|---|
| 5.10 | 5.10.270 | cb1afd087aed |
| 5.10 | 5.15.221 | 7719f6e7ed2f |
| 5.10 | 6.1.188 | b1e95e3602d8 |
| 5.10 | 6.6.157 | c3457a5aae5f |
| 5.10 | 6.12.109 | 8bfe746afee3 |
| 5.10 | 6.18.50 | b8282668d8fa |
| 5.10 | 7.2.4 | 565038b0092f |
| 5.10 | 7.3 | 505b6d296c48 |
| 4.19.162 | 0 | 0 |
| 5.4.82 | 0 | 0 |
| 5.9.13 | 0 | 0 |
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 bug is in ip6gre/ip6gretap/ip6erspan link configuration and local transmit: rtnetlink creates the devices, then sendmsg/forwarding uses the inflated hard_header_len. Incoming GRE receive (gre_rcv) does not perform this accounting, and a remote peer cannot build the stacked topology.
- AC:LAttack complexity, low
- An unprivileged attacker fully controls both sides: creating a stack of ip6gretap/ip6erspan devices so each ip6gre_tnl_link_config_route() copies lower hard_header_len plus t_hlen, then sending packets through that stack. No race or victim-side state is required.
- PR:LPrivileges required, low
- Creating these tunnels needs CAP_NET_ADMIN, but rtnetlink checks it with netlink_ns_capable()/sk_ns_capable() against net->user_ns, so an unprivileged user obtains it via unshare -Urn without init-namespace root.
- UI:NUser interaction, none
- The attacker creates the stacked ip6gre devices and generates the traffic that drives IP output and header reservation; no other user or administrator action is required.
- S:UScope, unchanged
- The resulting skb header-offset wrap corrupts kernel heap in the same OS security authority. This is standard in-kernel privilege escalation, not a VM, IOMMU, or hypervisor boundary crossing.
- C:HConfidentiality impact, high
- Inflated hard_header_len makes LL_RESERVED_SPACE exceed 16-bit skb offsets; after pskb_expand_head the u16 network_header wraps so flow-dissect/skb_pull read from headroom or unrelated heap, enabling arbitrary disclosure as in CVE-2026-80978.
- I:HIntegrity impact, high
- Post-wrap, eth_header/ip6gre_header skb_push and tunnel xmit write outer headers at the corrupted skb->data, giving an out-of-bounds write into unrelated kernel heap that can be used for control-flow hijacking.
- A:HAvailability impact, high
- Wrapped offsets cause kernel oops/panic (page fault in __skb_flow_dissect, KASAN UAF, or skb_under_panic when unsigned short hard_header_len itself wraps), matching the confirmed crash of the companion tunnel-headroom bug.