CVE-2026-89563: ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit()
In the Linux kernel, the following vulnerability has been resolved:
ip6tunnel: use skbcowhead() in ip6tnlxmit()
ip6tnlxmit() may need to expand headroom before it can push the outer IPv6 and optional encap headers. It currently does that with skbreallocheadroom(), copies skb->sk ownership, consumes the original skb, and then continues processing with the replacement skb kept only in its local variable.
That is safe only if the helper cannot fail afterwards. But this helper still has post-reallocation error exits. collectmd tunnels reject non-NONE encap after the replacement, and ip6tnlencap() can also fail later. In those cases the helper returns an error to its callers while the caller still only has the original skb pointer.
Both ip6tnlstartxmit() and the IPv6 GRE paths free the caller skb on error, so they can end up freeing an skb that ip6tnlxmit() already consumed.
Use skbcowhead() instead. It provides the required headroom and writability without privately replacing the caller-owned skb, so later error returns cannot leave callers with a stale pointer.
The Ethernet users, ip6gretap and ip6erspan, clear IFFTXSKBSHARING and already call skbcowhead() before entering ip6tnlxmit(). They do not rely on the removed skbshared() reallocation. This also makes the IPv6 tunnel path consistent with iptunnelxmit().
Event History
Frequently Asked Questions
Which packet paths can trigger the stale-SKB error handling issue?
The affected callers named are ip6_tnl_start_xmit() and the IPv6 GRE paths. They may free the caller-owned skb after ip6_tnl_xmit() returns an error, even though the prior headroom reallocation may already have consumed that skb.
What conditions are needed for the problematic error path?
ip6_tnl_xmit() must need to expand packet headroom and then encounter an error after skb_realloc_headroom() has replaced the skb. Documented post-reallocation failures include collect_md tunnels using a non-NONE encapsulation and failures from ip6_tnl_encap().
Do the Ethernet tunnel users follow the same vulnerable handling?
The description identifies ip6gretap and ip6erspan as already clearing IFF_TX_SKB_SHARING and calling skb_cow_head() before transmission. That avoids privately replacing the caller-owned skb in the manner described for the affected paths.