CVE-2026-63872

What it actually does

This flaw is a Linux kernel IPsec ESP memory-reference leak in the ESP output path for both IPv4 and IPv6. When ESP processing replaces packet page fragments for non-in-place encryption and a subsequent scatter-gather vector build fails, the kernel frees temporary metadata but fails to release references to the original packet page fragments. Repeated failures can leave pages permanently referenced, causing unreclaimable memory growth and eventual denial of service through memory exhaustion, networking instability, or kernel OOM behavior. The issue does not directly provide code execution, data disclosure, or privilege escalation; its primary impact is availability loss.

Why it matters to the business

Systems that rely on Linux IPsec ESP for VPNs, site-to-site tunnels, encrypted overlays, or host-to-host encryption could become unstable or unavailable if exposed to repeated trigger conditions. Operational consequences may include dropped VPN connectivity, degraded network throughput, service outages, node reboots, or emergency failover. Although current public exploit maturity is listed as none, the CVSS availability impact is high and the attack complexity is low once a vulnerable ESP processing path is reachable, so internet- or partner-facing IPsec gateways should be treated as higher priority.

How an attack unfolds

An attacker targets a Linux system that processes outbound ESP traffic through the vulnerable kernel path, typically a VPN endpoint, IPsec gateway, or host using XFRM/IPsec policies. The attacker causes traffic to be handled in the non-in-place ESP output path and repeatedly drives conditions where the destination scatter-gather vector construction fails after the source scatterlist has already captured references to the original packet fragments. On each failure, the vulnerable cleanup path frees only temporary allocation state and does not drop references to the old page fragments. Over time, these leaked references prevent memory from being reclaimed. Continued triggering can exhaust available memory or destabilize the networking stack, resulting in dropped tunnels, process termination by the OOM killer, kernel warnings, or system unavailability.

How to fix it

Apply a Linux kernel update containing the upstream fix for the ESP page-fragment reference leak in both esp4 and esp6. Because no fixed package list was provided, use the latest security kernel from the operating system or appliance vendor and confirm the vendor advisory explicitly includes this CVE or the ESP/XFRM fix for the skb_to_sgvec failure cleanup path. Reboot into the patched kernel after installation; live patching should only be considered sufficient if the vendor states this specific fix is included and active. As temporary mitigations, reduce exposure of IPsec endpoints to untrusted networks where possible, restrict ESP/IKE access to known peers with firewall or security-group rules, disable unused IPsec/XFRM configurations, monitor memory pressure closely, and consider failover to patched gateways for critical VPN paths.

How to confirm the fix worked

Confirm exposure by inventorying Linux systems that use IPsec ESP, XFRM policies, strongSwan, libreswan, NetworkManager IPsec profiles, VPN concentrator roles, encrypted overlay networking, or kernel ESP modules. Validate remediation by checking the running kernel version after reboot and matching it against the vendor-fixed kernel release, not only the installed package version. Verify that esp4 and esp6 code paths are from the patched kernel build. Functional validation should include IPsec tunnel establishment, sustained encrypted traffic, and monitoring for stable memory usage under load. Exposure checks can include reviewing loaded modules and active XFRM state with commands such as lsmod, ip xfrm state, ip xfrm policy, and vendor package-management tools.

Typical attack path

1. Identify or reach a Linux host, VPN concentrator, gateway, or workload that uses IPsec ESP for encrypted traffic.
2. Send or induce traffic that is processed through the ESP output path, including IPv4 ESP, IPv6 ESP, or XFRM-managed IPsec policies.
3. Create repeated packet-fragmentation and memory-pressure conditions that cause the second skb_to_sgvec operation to fail after source page fragments have been captured.
4. Repeat the trigger so old packet page fragments remain referenced and unreclaimable.
5. Allow leaked page references to accumulate until the host experiences memory pressure, network degradation, OOM events, tunnel failure, or service outage.

How to detect it

Look for evidence of availability-focused exploitation or attempted triggering rather than classic compromise artifacts. Relevant telemetry includes kernel logs, system journal, dmesg output, crash dumps, OOM-killer logs, VPN/IPsec gateway logs, firewall flow records, NetFlow/IPFIX, and monitoring data for memory usage and tunnel health. Investigate unexplained memory growth on systems with active ESP/XFRM policies, especially if correlated with spikes in ESP traffic, IPsec tunnel churn, packet-fragmentation anomalies, or repeated allocation failures. Kernel logs may show page allocation failures, OOM events, stack traces involving ESP/XFRM functions, or network stack instability. Because no public exploit indicators or threat actors are known from the supplied data, absence of a specific signature does not rule out triggering; use behavioral correlation around ESP traffic and memory exhaustion.

• esp_output_tail
• skb_to_sgvec
• esp_ssg_unref
• xfrm
• esp4
• esp6
• page allocation failure
• Out of memory: Killed process
• oom-killer
• Memory allocation failure
• IPsec tunnel down
• XFRM
• NETDEV WATCHDOG

What your security team should do

• Prioritize patching Linux IPsec gateways, VPN concentrators, border systems, Kubernetes or cloud nodes using encrypted overlays, and any hosts processing untrusted ESP traffic.
• Restrict IKE, ESP, and related VPN access to approved peer IP addresses until patching is complete.
• Inventory systems with active XFRM/IPsec policies and loaded esp4 or esp6 modules; treat these as potentially exposed even if no user-space VPN daemon is obvious.
• Monitor memory pressure, kernel allocation failures, OOM-killer activity, IPsec tunnel resets, and unusual ESP traffic volume until patched systems are confirmed stable.
• After patching, reboot and verify the running kernel is the fixed kernel; installed-but-not-running kernel packages do not remediate the issue.
• Review crash dumps, kernel logs, and VPN gateway telemetry from the period since publication for unexplained memory exhaustion or ESP/XFRM-related failures.
• Because this is not currently in CISA KEV and has no known public exploit maturity, balance urgency with exposure: externally reachable or high-availability IPsec infrastructure should be patched first.