CVE-2026-53240

What it actually does

This is a Linux kernel use-after-free in the XFRM IP-TFS packet reassembly path. A race condition allows one CPU or timer path to complete reassembly and free an skb while another execution path still treats the same skb as valid, leading to operations such as trimming, checksum handling, or skb consumption on freed memory from skbuff_head_cache. Depending on kernel configuration, timing, and memory layout, impact may range from kernel crash and denial of service to potential memory corruption with elevated code execution risk in kernel context. Exploitability is expected to require access to a system processing affected XFRM/IP-TFS traffic and the ability to trigger specific reassembly timing conditions.

Why it matters to the business

Systems using affected Linux kernels with XFRM/IP-TFS functionality may be vulnerable to crashes or instability in network packet processing, which can disrupt VPN, tunnel, gateway, or network security infrastructure. Although this issue is not currently listed in CISA KEV, has no known public exploit maturity, and has a low EPSS score of 0.0039, kernel memory-safety bugs should still be prioritized where exposed on internet-facing or high-availability network paths because successful exploitation can affect system availability and potentially compromise the host.

How an attack unfolds

An attacker would need to send or cause processing of crafted IP-TFS/XFRM traffic that enters the vulnerable partial reassembly path. The vulnerable function stores an skb pointer as the first packet for reassembly, releases the lock, and later checks shared reassembly state without holding the lock. If a concurrent CPU or the drop timer completes or aborts reassembly during this window, the skb can be freed while the original execution path still holds the stale pointer. The attacker attempts to win this race repeatedly by controlling packet timing, fragmentation/reassembly behavior, and traffic volume. A successful race can cause the kernel to access freed skb memory, commonly resulting in a kernel oops, panic, or networking subsystem crash; in a more advanced scenario, careful heap shaping could potentially turn the memory corruption into privilege escalation or code execution in kernel context. There are no named threat actors, ransomware campaigns, or known exploited-in-the-wild reports provided for this vulnerability.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the XFRM IP-TFS use-after-free in __input_process_payload. No exact fixed package versions were provided in the input, so track the fix through your Linux distribution vendor advisories and kernel stable update channels. Prioritize systems that enable XFRM/IPsec/IP-TFS, VPN gateways, security appliances, routers, tunnel endpoints, and high-availability network infrastructure. If immediate patching is not possible, reduce exposure by disabling unused IP-TFS functionality, limiting who can send traffic into affected XFRM/IPsec tunnel endpoints, applying network ACLs, rate-limiting untrusted tunnel traffic where operationally safe, and ensuring kernel crash dump collection is enabled for incident analysis.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel includes the vendor backport or upstream commit that replaces the unlocked ra_newskb ownership check with a local ownership flag in the XFRM IP-TFS input reassembly path. Validate both installed and running kernel versions because a reboot is usually required after kernel updates. Review distribution advisories for this CVE and confirm the package version is listed as fixed. On hosts where IP-TFS is not required, validate that the feature or relevant tunnel configuration is disabled. Where feasible, run vendor-supported regression or traffic tests for IPsec/IP-TFS tunnels and confirm there are no kernel oops, KASAN, or skb-related errors under reassembly-heavy traffic.

Typical attack path

1. Identify a target running an affected Linux kernel with XFRM/IP-TFS traffic processing enabled or reachable through an IPsec/IP-TFS tunnel path.
2. Send crafted or high-rate IP-TFS/XFRM traffic designed to enter partial payload reassembly.
3. Manipulate packet ordering, timing, or fragmentation characteristics to create contention between normal input processing, continuation reassembly, and the drop timer.
4. Trigger the race where one execution path frees the skb while another path continues using the stale first_skb pointer.
5. Cause kernel memory corruption, typically observed as a kernel oops, panic, service interruption, or host reboot; advanced exploitation may attempt to escalate impact beyond denial of service.

How to detect it

There is no unique, reliable network IOC that proves exploitation of this race condition. Detection should focus on evidence of kernel instability or memory-safety failures during XFRM/IPsec/IP-TFS traffic processing. Review kernel logs from journald, dmesg, syslog, netconsole, crash dumps, and EDR kernel telemetry for oops or panic events referencing XFRM, IP-TFS, skb handling, __input_process_payload, iptfs_reassem_cont, pskb_trim, consume_skb, skbuff_head_cache, KASAN, slab-use-after-free, or general protection faults. Correlate any such events with bursts of tunnel traffic, malformed or unusual IPsec/IP-TFS packets, tunnel rekeying/reassembly anomalies, interface resets, host reboots, or service watchdog restarts. If crash dumps are available, inspect stack traces for the vulnerable functions and confirm whether the faulting object is an skb from skbuff_head_cache. Because no known exploited-in-the-wild activity or public exploit maturity was provided, treat matching artifacts as suspicious but not definitive without corroborating timing, traffic, and crash evidence.

• __input_process_payload
• iptfs_reassem_cont
• ra_newskb
• first_skb
• skbuff_head_cache
• pskb_trim
• consume_skb
• xfrm
• iptfs
• IP-TFS
• KASAN: use-after-free
• BUG: KASAN: slab-use-after-free
• BUG: KASAN: use-after-free
• kernel BUG
• kernel panic
• Oops:
• general protection fault
• use-after-free
• slab-use-after-free
• skb_release_data
• kfree_skb

What your security team should do

• Inventory Linux systems that act as IPsec, XFRM, IP-TFS, VPN, tunnel, router, firewall, or network gateway endpoints.
• Prioritize patching exposed or high-availability network infrastructure even though the vulnerability is not currently in KEV and has low EPSS.
• Confirm whether IP-TFS is enabled; if unused, disable it or remove related tunnel configurations as a compensating control.
• Monitor kernel logs for skb, XFRM, IP-TFS, KASAN, use-after-free, general protection fault, and panic messages until all affected systems are remediated.
• Ensure kernel crash dumps, persistent journaling, and centralized syslog collection are enabled on critical Linux network systems.
• After patching, reboot systems into the fixed kernel and verify the active runtime kernel, not just the installed package.
• Review vendor advisories regularly because exact fixed versions may differ across distributions and long-term-support kernel branches.