ZeroHour

CVE-2026-89562

mass

Incorrect hard_header_len in Linux kernel IPv6 GRE tunnels (ip6_gre)

CVSS 3.1
7.8 high
EPSS
Published
()
Modified
AI analysis

A flaw in the Linux kernel's IPv6 GRE tunneling code causes ip6gre_tnl_link_config_route() to wrongly fold the lower (underlying) device's hardware header length into the tunnel device's hard_header_len whenever header_ops is set. This mis-sizes the headroom reserved for outgoing packets on NBMA ip6gre tunnels and incorrectly inflates hard_header_len on ip6gretap and ip6erspan devices, which have a fixed Ethernet header length, potentially leading to kernel memory corruption during packet transmission. A local attacker with low privileges on an affected host who can influence tunnel packet paths could leverage this for a system crash (denial of service) or, at worst, privilege escalation, consistent with the high local-vector CVSS 7.8 rating. Affected systems are those running kernels containing this ip6_gre code, primarily servers, routers, and gateways configured with ip6gre, ip6gretap, or ip6erspan tunnels. No public proof of concept is known and the issue is not listed in CISA's KEV catalog, so exploitation status is none known.

What to do: Patch to a kernel release containing this ip6_gre fix as soon as your distribution ships it. Audit hosts for ip6gre, ip6gretap, or ip6erspan tunnel configurations, especially NBMA setups over lower devices with header_ops set, since those are where the mis-sized hardware header is triggered. As an interim measure, unprivileged local users should not be able to create or manipulate tunnel devices (restrict CAP_NET_ADMIN) on unpatched systems.

Affected
Linux kernel (ip6_gre tunneling subsystem)
Estimated exposure
massbillions of Linux devices ship the affected kernel code; the subset actually running IPv6 GRE/tap/ERSPAN tunnels is plausibly in the low millions of hosts — The Linux kernel underpins billions of servers, routers, embedded systems, and Android devices, but the vulnerable code path is only exercised on hosts with ip6_gre-family tunnels configured, which is a much smaller deployment population…

Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.

Description

In the Linux kernel, the following vulnerability has been resolved: ip6_gre: fix hardware header length for NBMA tunnels 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.

Vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

In the news

No ingested article mentions this CVE yet.