ZeroHour

CVE-2026-89563

mass

Use-After-Free in Linux Kernel IPv6 Tunnel Transmit Path (ip6_tnl_xmit)

CVSS 3.1
7.8 high
EPSS
Published
()
Modified
AI analysis

The Linux kernel's IPv6 tunnel transmit function ip6_tnl_xmit() expands skb headroom using skb_realloc_headroom(), which privately replaces and consumes the caller-owned socket buffer, yet the function can still return errors afterwards (collect_md tunnels rejecting non-NONE encap, or a failing ip6_tnl_encap()). Callers such as ip6_tnl_start_xmit() and the IPv6 GRE transmit paths only hold the original skb pointer and free it on error, resulting in a double-free/use-after-free of kernel memory. A local attacker with low privileges who can steer traffic through an affected IPv6 tunnel configuration (ip6tnl, ip6gre, ip6gretap, ip6erspan) could trigger the bug to crash the kernel or potentially escalate privileges, given the high confidentiality/integrity/availability impact (CVSS 3.1: 7.8, local vector). The fix replaces skb_realloc_headroom() with skb_cow_head(), which never substitutes the caller's skb, eliminating the stale-pointer error paths. No public proof of concept is known, the flaw is not in CISA's KEV, and no exploitation in the wild has been reported.

What to do: Apply your distribution's kernel update containing the skb_cow_head() fix for ip6_tnl_xmit() and reboot into the patched kernel. On multi-user or container-hosting systems that cannot be patched immediately, restrict unprivileged user/network namespaces (e.g., sysctl kernel.unprivileged_userns_clone=0 or lowering user.max_user_namespaces), since unprivileged namespace creation is the typical route to building ip6tnl/ip6gre tunnels. Watch for kernel oopses or crashes referencing ip6_tnl_xmit, ip6_tnl_start_xmit, or GRE transmit paths, and audit whether IPv6 tunnels or collect_md (flow-based) tunnels are configured on exposed hosts.

Affected
Linux kernel (ip6_tunnel / IPv6 tunnel and IPv6 GRE transmit paths, incl. ip6tnl, ip6gre, ip6gretap, ip6erspan)
Estimated exposure
massPotentially billions of Linux systems and devices (mainline kernel networking code), though practical risk is limited to machines where untrusted local users… — The ip6_tunnel code is part of the mainline Linux kernel shipped in essentially every Linux distribution, Android device, and embedded system worldwide, so the code is ubiquitous even though the vulnerable path requires local access and…

Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.

Description

In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit() ip6_tnl_xmit() may need to expand headroom before it can push the outer IPv6 and optional encap headers. It currently does that with skb_realloc_headroom(), 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. collect_md tunnels reject non-NONE encap after the replacement, and ip6_tnl_encap() 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 ip6_tnl_start_xmit() and the IPv6 GRE paths free the caller skb on error, so they can end up freeing an skb that ip6_tnl_xmit() already consumed. Use skb_cow_head() 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 IFF_TX_SKB_SHARING and already call skb_cow_head() before entering ip6_tnl_xmit(). They do not rely on the removed skb_shared() reallocation. This also makes the IPv6 tunnel path consistent with ip_tunnel_xmit().

Vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

In the news

No ingested article mentions this CVE yet.