CVE-2026-53363

What it actually does

This is a Linux kernel memory-corruption flaw in the XFRM IP-TFS/IPsec packet handling path. During fragment transfer between socket buffers, iptfs_consume_frags() fails to preserve the SKBFL_SHARED_FRAG marker, which can cause ESP processing to incorrectly treat shared or read-only page-cache-backed fragments as safe for in-place encryption. The result can be kernel memory corruption, page-cache corruption, kernel crash, and, depending on allocator state and exploitability, potential privilege escalation or remote kernel-code execution on systems processing affected IPsec/IP-TFS traffic.

Why it matters to the business

Systems acting as Linux IPsec gateways, VPN endpoints, or hosts using XFRM IP-TFS may be exposed to unauthenticated network-triggered kernel compromise or denial of service. A successful attack could disrupt VPN connectivity, crash critical network infrastructure, or give an attacker control of the affected Linux host. Although the CVSS score is critical, EPSS is currently low, the issue is not listed in CISA KEV, and no public exploit maturity is reported, so prioritization should focus first on internet-facing or partner-facing IPsec/IP-TFS systems.

How an attack unfolds

An attacker targets a Linux system that processes XFRM/IPsec traffic using the vulnerable IP-TFS code path. They send crafted network traffic that causes paged fragments to be moved between socket buffers by iptfs_consume_frags(). Because the shared-fragment marker is lost, later ESP handling may incorrectly perform in-place encryption on fragments backed by shared or read-only page-cache memory. This can corrupt kernel memory or trigger a kernel fault. In the simplest case, exploitation causes a kernel panic or service outage; in a more advanced exploit, the attacker would shape memory layout and packet timing to turn the corruption primitive into kernel privilege escalation or code execution.

How to fix it

Upgrade affected Linux kernels to a vendor release that includes the upstream fix for the XFRM IP-TFS shared-fragment marker preservation issue. Because no exact fixed versions were provided, use distribution security advisories and kernel changelogs to identify the corrected package, then reboot into the updated kernel. Where immediate patching is not possible, reduce exposure by disabling unused IP-TFS/XFRM functionality, limiting IPsec peers to trusted source addresses, blocking unsolicited ESP and IKE/NAT-T traffic at network boundaries, and avoiding exposure of IPsec endpoints to untrusted networks. Kernel live patching may reduce risk only if the vendor explicitly covers this fix; otherwise a rebooted kernel update is required.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, contains the vendor backport or upstream fix. Review distribution advisories, kernel changelogs, or source patches for the iptfs_consume_frags() change that preserves SKBFL_SHARED_FRAG. Validate that exposed systems no longer run vulnerable kernels after reboot. Check whether IPsec/XFRM/IP-TFS is enabled or reachable using host configuration, firewall policy, and network exposure reviews. Where feasible in a lab, exercise IPsec/IP-TFS traffic under the patched kernel and confirm no kernel warnings, oopses, KASAN reports, or ESP/XFRM crashes occur.

Typical attack path

1. Identify Linux hosts or gateways reachable over IPsec-related network paths, especially ESP, UDP/500, or UDP/4500.
2. Determine whether the target is likely using XFRM IP-TFS or an affected kernel build.
3. Send crafted IPsec/IP-TFS traffic that exercises fragment consumption and ESP processing.
4. Trigger loss of the shared-fragment marker during socket-buffer fragment transfer.
5. Cause unsafe in-place encryption against shared or read-only page-backed fragments.
6. Leverage the resulting kernel memory corruption to crash the host or attempt kernel-level code execution.

How to detect it

There is no reliable single log entry that proves exploitation, and no public exploit-specific network signature is currently known. Hunt for suspicious activity around Linux systems that terminate or process IPsec traffic: kernel oops, panic, BUG, KASAN, page fault, or memory-corruption messages referencing XFRM, IP-TFS, ESP, skb fragments, or iptfs_consume_frags(); unexpected crashes or reboots of IPsec gateways; unusual spikes in ESP protocol 50, UDP/500, or UDP/4500 traffic; and connection attempts from unknown peers shortly before kernel faults. Review system journal, dmesg, kdump/vmcore artifacts, firewall logs, VPN daemon logs such as strongSwan or libreswan, NetFlow, packet captures, and audit logs for xfrm policy or state changes. Because exploitation occurs in kernel packet processing, absence of application logs does not rule out exploitation.

• iptfs_consume_frags
• SKBFL_SHARED_FRAG
• xfrm: iptfs
• xfrm
• IP-TFS
• esp_output
• esp_input
• skb_try_coalesce
• KASAN:
• BUG: kernel
• kernel panic
• Oops:
• general protection fault
• unable to handle kernel paging request
• protocol 50
• UDP/500
• UDP/4500

What your security team should do

• Prioritize patching Linux IPsec gateways, VPN concentrators, edge routers, and hosts exposed to untrusted ESP, IKE, or NAT-T traffic.
• Inventory systems using XFRM, IPsec, strongSwan, libreswan, or kernel IP-TFS features and map them to running kernel versions.
• Apply vendor kernel updates and reboot; do not rely solely on package installation status.
• Temporarily restrict ESP, UDP/500, and UDP/4500 to known trusted peers where business requirements allow.
• Monitor kernel logs and crash telemetry for XFRM, IP-TFS, ESP, skb, or page-fragment-related faults.
• Increase urgency if exploit code appears, EPSS rises materially, the issue is added to KEV, or threat actors begin targeting Linux IPsec infrastructure.