Cloudanix VulnDB

CVE-2026-89565

None

CVSS

—

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A rare Linux kernel networking bug can slowly leak memory when certain tunnel settings are active and the system runs low on memory, potentially causing network slowdowns or crashes.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
High
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Memory leak of sk_buff structures in the ipip receive path when ip_tun_rx_dst() fails to allocate metadata_dst in collect_md mode; ipip_tunnel_rcv() returns 0 without freeing the skb, and upstream tunnel handlers treat the packet as consumed.

Why it matters to the business

Gradual kernel memory exhaustion on systems using ipip or mplsip tunnels in collect_md mode under rare allocation-pressure conditions, potentially leading to degraded network performance or denial of service.

How an attack unfolds

An attacker sends traffic through an ipip or mplsip tunnel configured in collect_md mode while the system experiences an atomic allocation failure during metadata_dst creation; the skb is never freed and remains referenced only by the leaked structure.

How to fix it

Update the Linux kernel to a version containing the fix that jumps to the drop label instead of returning 0 on metadata_dst allocation failure in ipip_tunnel_rcv().

How to confirm the fix worked

Verify the presence of the corrected ipip_tunnel_rcv() logic (jump to drop label on ip_tun_rx_dst() failure) in the running kernel source or binary; confirm no skb leaks under synthetic allocation-failure testing with collect_md tunnels.

Typical attack path

  1. Configure or abuse an ipip/mplsip tunnel in collect_md mode on the target
  2. Induce or wait for an atomic GFP allocation failure inside ip_tun_rx_dst()
  3. Send crafted or normal tunnel traffic that reaches ipip_tunnel_rcv()
  4. Observe progressive skb leakage and eventual memory pressure

How to detect it

Inspect kernel slabinfo or kmemleak reports for unreleased sk_buff objects originating from ipip receive paths; correlate with tunnel configuration changes and allocation-failure events in dmesg.

What your security team should do

  • Prioritize kernel updates on any system exposing ipip or mplsip tunnels in collect_md mode
  • Monitor memory usage and slab statistics on affected hosts until patched
  • Disable collect_md mode where operationally feasible until remediation is complete

The record

In the Linux kernel, the following vulnerability has been resolved: ipip: fix skb leak in collect_md mode when metadata_dst allocation fails In collect_md mode ipip_tunnel_rcv() returns 0 without freeing the skb when ip_tun_rx_dst() fails to allocate the metadata_dst. ipip_rcv() and mplsip_rcv() are registered as xfrm_tunnel handlers, so tunnel4_rcv() and tunnelmpls4_rcv() read the zero return as "the packet has been consumed" and do not free it either. The skb is leaked. The other tunnel drivers all dispose of the packet at this point: ip6_tunnel.c jumps to its drop label, ip_gre.c and ip6_gre.c return PACKET_REJECT, which makes gre_rcv() free the skb. Only ipip returns 0. Jump to the existing drop label instead. It frees the skb and still returns 0, so the packet keeps being reported as consumed, which is what we want here: the outer header has already been pulled, and neither the remaining handlers nor an ICMP unreachable have any use for it. Triggering this needs an ipip or mplsip tunnel in collect_md mode and an atomic allocation failure, which is why it has gone unnoticed.

Affected packages

Ecosystem Package Introduced Fixed