CVE-2026-89562: ip6_gre: fix hardware header length for NBMA tunnels
In the Linux kernel, the following vulnerability has been resolved:
ip6gre: fix hardware header length for NBMA tunnels
ip6gretnllinkconfigroute() accumulates the lower device's hardware header length into dev->hardheaderlen whenever headerops is set. This is incorrect for both users of headerops.
ip6gretap and ip6erspan have a fixed Ethernet hardware header length. For an NBMA ip6gre tunnel, ip6greheader() 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 neededheadroom. Set hardheaderlen to the tunnel header length only for ARPHRDIP6GRE devices with headerops, and leave the fixed Ethernet header length unchanged for tap and erspan devices.
Event History
Frequently Asked Questions
Which deployments need to assess this fix?
Systems using NBMA ip6gre tunnels should be assessed. The issue concerns tunnel devices using header_ops where the lower device hardware header length was accumulated into the tunnel device's hard_header_len.
Does the handling differ for ip6gretap or ip6erspan devices?
Yes. ip6gretap and ip6erspan use a fixed Ethernet hardware header length, which should remain unchanged; the lower-device header is retained as needed headroom rather than included in the tunnel hardware header length.