CVE-2026-53228

What it actually does

This is a Linux kernel use-after-free condition in the SIT IPv6-over-IPv4 tunneling transmit path. The affected code caches a pointer to the inner IPv6 header, then calls the generic tunnel offload helper for GSO packets. Under cloned socket-buffer header conditions, that helper may expand or relocate the skb head, invalidating previously saved header pointers. If the code later reuses the stale IPv6-header pointer instead of reloading it, the kernel can read hop-limit and traffic-class data from memory that may already have been freed or reused. The most likely outcomes are kernel memory corruption symptoms, incorrect tunnel packet metadata, kernel warnings, or system crash; exploitability beyond denial of service is uncertain and no public exploit maturity is indicated.

Why it matters to the business

Systems that use Linux SIT tunnels for IPv6-over-IPv4 encapsulation may be exposed to reliability risk if crafted or naturally occurring GSO traffic triggers the vulnerable transmit path. Operationally, this can cause tunnel instability, packet loss, degraded IPv6 connectivity, or kernel crashes requiring node reboot. The current EPSS is low and the issue is not listed in CISA KEV, so broad active exploitation is not indicated, but Internet-facing tunnel endpoints, routers, gateways, Kubernetes/container hosts, and network appliances running affected kernels should still be prioritized because kernel crashes can disrupt critical connectivity.

How an attack unfolds

An attacker first needs a path that causes a vulnerable Linux system to transmit IPv6 traffic through a SIT IPv6-over-IPv4 tunnel. They then send or induce traffic patterns that result in GSO socket buffers with cloned headers entering the SIT transmit path. During encapsulation, the kernel's tunnel offload handling may unclone or expand the skb header, moving the underlying skb head and invalidating the previously cached pointer to the inner IPv6 header. The vulnerable code continues to use that stale pointer to read the inner IPv6 hop limit and DS/traffic-class field. If the old skb head has been freed or reused, this becomes a use-after-free read in kernel context. A practical attack would likely aim to crash the kernel or destabilize the tunnel; reliable privilege escalation or code execution is not established from the available information.

How to fix it

Update the Linux kernel to a version that includes the SIT tunnel fix that reloads the inner IPv6 header pointer after successful offload handling and before subsequent header reads. If vendor packages are used, apply the relevant distribution kernel security update rather than attempting to patch the kernel manually. Where immediate patching is not possible, reduce exposure by disabling unused SIT tunnels, unloading or preventing use of the sit tunnel module where operationally safe, restricting who can send traffic into tunnel endpoints, disabling or limiting GSO/TSO offloads for affected tunnel paths as a temporary risk reduction, and monitoring for kernel instability. Because no exact fixed package versions were provided, use the fixed kernel builds published by the operating-system or appliance vendor for this vulnerability.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel build includes the upstream fix for the SIT transmit path and that the system has rebooted into the patched kernel, not only installed it. Check vendor advisories or package changelogs for the vulnerability identifier or for references to reloading the inner IPv6 header after GSO/offload handling in ipip6_tunnel_xmit. Validate exposure by inventorying systems with SIT enabled or configured, checking for loaded sit tunnel support, and reviewing active tunnel interfaces. Where safe in a test environment, reproduce representative IPv6-over-IPv4 tunnel traffic with GSO enabled and confirm there are no kernel warnings, KASAN reports, oopses, or crashes in the SIT transmit path.

Typical attack path

1. Identify a Linux host, router, gateway, or appliance using SIT IPv6-over-IPv4 tunneling.
2. Establish a traffic path that causes the target to encapsulate IPv6 packets into IPv4 via the SIT tunnel transmit path.
3. Send or induce high-volume or specially shaped IPv6 traffic that uses GSO and cloned skb headers.
4. Trigger skb header unclone or expansion during tunnel offload processing, causing the skb head to move.
5. Cause the vulnerable code to reuse the stale cached IPv6-header pointer after the skb head has changed.
6. Leverage the resulting use-after-free read to cause kernel warnings, tunnel malfunction, packet metadata corruption, or kernel crash.

How to detect it

There are no unique network indicators that prove exploitation because the trigger occurs inside normal-looking SIT IPv6-over-IPv4 tunnel processing. To look for possible prior exploitation, review kernel logs, system journals, crash dumps, and monitoring alerts from systems that have SIT tunnels enabled. Focus on kernel oops, panic, KASAN, slab, or use-after-free messages that mention the SIT driver, ipip6_tunnel_xmit, skb_header_unclone, pskb_expand_head, GSO, or skb head expansion. Correlate any crashes with bursts of IPv6-over-IPv4 protocol 41 traffic, increased tunnel throughput, abnormal GSO/offload activity, or repeated tunnel interface resets. On hardened or debug kernels, KASAN reports are the strongest artifact; on production kernels, evidence may be limited to generic kernel panics, soft lockups, or abrupt reboots. Network telemetry can help identify suspicious precursor activity, especially high-volume or unusual protocol 41 traffic to or from SIT endpoints, but it will not by itself confirm exploitation.

• ipip6_tunnel_xmit
• skb_header_unclone
• pskb_expand_head
• BUG: KASAN: use-after-free
• KASAN: use-after-free
• kernel BUG at net/ipv6/sit.c
• Oops:
• Kernel panic
• sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
• protocol 41
• IPv6-over-IPv4
• sit0

What your security team should do

• Inventory Linux systems and network appliances that use SIT, IPv6-over-IPv4, or protocol 41 tunneling.
• Prioritize patching tunnel endpoints, routers, gateways, virtualization hosts, and systems exposed to untrusted tunnel traffic.
• Apply vendor kernel updates and reboot systems into the fixed kernel; verify the running kernel version after reboot.
• Disable unused SIT tunnels or block unneeded IPv6-over-IPv4 tunnel traffic at network boundaries.
• Temporarily reduce risk on unpatched critical systems by restricting tunnel sources and, where operationally acceptable, disabling relevant offload features on affected paths.
• Monitor kernel logs for use-after-free, KASAN, oops, panic, or crash messages involving SIT, ipip6_tunnel_xmit, skb_header_unclone, or pskb_expand_head.
• Treat unexplained crashes on SIT tunnel endpoints as potentially security-relevant until logs and crash dumps are reviewed.
• Because EPSS is currently low and there is no KEV listing, balance urgency against operational risk, but do not defer indefinitely on systems providing critical network connectivity.