CVE-2026-89565: ipip: fix skb leak in collect_md mode when metadata_dst allocation fails
In the Linux kernel, the following vulnerability has been resolved:
ipip: fix skb leak in collectmd mode when metadatadst allocation fails
In collectmd mode ipiptunnelrcv() returns 0 without freeing the skb when iptunrxdst() fails to allocate the metadatadst. ipiprcv() and mplsiprcv() are registered as xfrmtunnel handlers, so tunnel4rcv() and tunnelmpls4rcv() 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: ip6tunnel.c jumps to its drop label, ipgre.c and ip6gre.c return PACKETREJECT, which makes grercv() 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 collectmd mode and an atomic allocation failure, which is why it has gone unnoticed.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this skb leak?
Exposure requires an IPIP or MPLS-over-IP tunnel configured in collect_md mode. Systems without either of those tunnel types in collect_md mode are not described as affected.
What must happen to trigger the leak?
A packet must be received through the affected tunnel while allocation of metadata_dst fails in an atomic context. The failed allocation causes the receive path to report the packet as consumed without freeing its skb.
What is the practical impact of a successful trigger?
The packet buffer is leaked. Repeated triggering could accumulate leaked skbs, though the provided information does not quantify the resulting resource impact.
How can I determine whether my configuration is relevant?
Check whether the host has IPIP or MPLS-over-IP tunnels operating in collect_md mode. The issue is specifically tied to receive handling for those tunnel configurations and an atomic metadata_dst allocation failure.