Cloudanix VulnDB

CVE-2026-89562

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in how Linux handles certain network tunnels could let someone on the same computer corrupt memory and take over the system or crash it.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Incorrect accumulation of lower device hardware header length into the tunnel device's hard_header_len for NBMA ip6gre tunnels, causing the kernel to miscalculate required headroom and potentially write beyond allocated buffers when header_ops are present.

Why it matters to the business

Local attackers with access to a Linux system can trigger kernel memory corruption, leading to crashes, denial of service, or potential privilege escalation that disrupts network services and compromises host integrity.

How an attack unfolds

An attacker with local access configures or uses an NBMA ip6gre tunnel, sends crafted packets that exercise ip6gre_header and link configuration paths, and triggers the incorrect hard_header_len value to cause an out-of-bounds write during header construction.

How to fix it

Update to a Linux kernel containing the fix for incorrect hard_header_len handling in ip6_gre; ensure net/ipv6/ip6_gre.c uses needed_headroom for lower device headers and sets hard_header_len only to the tunnel header length for ARPHRD_IP6GRE devices.

How to confirm the fix worked

Confirm the patch is applied by inspecting the ip6gre_tnl_link_config_route function and verifying that lower device header length is stored in needed_headroom rather than hard_header_len; test tunnel creation and packet transmission under load.

Typical attack path

  1. Obtain local shell or code execution on an affected Linux kernel host
  2. Create or modify an ip6gre NBMA tunnel interface that enables header_ops
  3. Invoke tunnel configuration or transmit packets that call ip6gre_tnl_link_config_route and ip6gre_header
  4. Trigger buffer overflow or corruption via miscalculated header length
  5. Escalate privileges or cause kernel panic

How to detect it

Review kernel logs for oops or warnings mentioning ip6gre_header or hard_header_len; inspect audit logs for creation of ip6gre tunnel interfaces by untrusted users; examine network configuration changes around the time of any crashes.

What your security team should do

  • Prioritize kernel upgrades on all systems using ip6gre or ip6gretap tunnels
  • Restrict unprivileged local access to hosts with GRE tunnel configurations until patched
  • Monitor for kernel oops or crashes related to ip6_gre after applying updates

The record

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.

Affected packages

Ecosystem Package Introduced Fixed