CVE-2026-52932

What it actually does

This Linux kernel flaw is an error-path resource leak in the XFRM IPComp implementation. When asynchronous compression/decompression handling returns an error, destination scatter-gather pages allocated for the operation may not be freed. Repeatedly triggering the failing path can consume kernel memory over time, potentially causing memory pressure, packet processing degradation, service instability, or a system-wide denial of service. The issue is most relevant to systems using IPsec/XFRM with IPComp enabled or exposed through VPN/security-gateway functionality.

Why it matters to the business

Affected Linux systems that use IPsec compression can become unstable or unavailable if the vulnerable code path is repeatedly triggered. For organizations relying on Linux-based VPN concentrators, firewalls, routers, or hosts using IPsec/IPComp, this can interrupt secure connectivity and degrade network operations. The currently reported exploitation maturity is none, EPSS is low, and it is not listed in CISA KEV, so urgency is lower than actively exploited vulnerabilities, but internet-facing or high-availability IPsec systems should still be prioritized for patching during normal maintenance windows.

How an attack unfolds

An attacker first needs a path to exercise the Linux XFRM IPComp code, typically by interacting with a system configured for IPsec compression or by causing IPComp processing through an established or reachable IPsec configuration. The attacker then sends traffic or induces conditions that cause the asynchronous compression operation to fail. On vulnerable kernels, the failure path does not release destination scatter-gather pages correctly. By repeating this process, the attacker can gradually exhaust kernel memory or increase memory pressure until networking performance degrades, services fail, or the host requires recovery. Where IPComp is not configured or reachable, practical exploitability is significantly reduced.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the upstream fix for the XFRM IPComp error-path page free issue. No exact fixed package versions were provided, so administrators should consult their distribution advisories for this CVE and upgrade to the vendor-designated fixed kernel. After updating, reboot into the patched kernel and verify the running kernel version, not just the installed package version. If immediate patching is not possible, reduce exposure by disabling IPComp where it is not required, limiting IPsec/IPComp access to trusted peers, enforcing anti-spoofing and rate controls on IPsec endpoints, and monitoring memory pressure on systems that process IPsec traffic.

How to confirm the fix worked

Confirm whether the running kernel is vulnerable by checking the active kernel version against the relevant distribution or appliance security advisory for this issue. Validate that the host has rebooted into the fixed kernel after patch installation. Review IPsec/XFRM configuration to determine whether IPComp is enabled or negotiated. Where safe, confirm that IPComp is disabled if not required. Monitor kernel memory usage, slab/page allocation behavior, and IPsec error counters before and after remediation; patched systems should not show unbounded memory growth when IPComp compression errors occur. For appliances, validate firmware or OS image versions against the vendor's fixed release notes.

Typical attack path

1. Identify a Linux host, VPN gateway, router, firewall, or appliance using the kernel XFRM/IPsec stack with IPComp enabled.
2. Establish or reach traffic paths that are processed by the IPComp transform.
3. Send crafted, malformed, or high-volume IPComp-related traffic intended to force compression/decompression errors.
4. Repeat the error-triggering traffic so leaked destination pages accumulate in kernel memory.
5. Cause memory pressure, packet processing failures, service disruption, or system instability resulting in denial of service.

How to detect it

To assess possible prior exploitation, review systems that run IPsec/XFRM with IPComp enabled for unexplained memory pressure, kernel out-of-memory events, VPN instability, and bursts of IPsec or XFRM processing errors. Useful log sources include kernel logs, system journal, syslog, VPN/IPsec daemon logs, firewall logs, network telemetry, and availability monitoring. Look for repeated IPComp-related errors, sudden increases in memory usage without a corresponding user-space process, OOM killer activity, soft lockups, packet drops, or tunnel resets around periods of unusual inbound IPsec traffic. Network teams should review packet captures or flow logs for unexpected IP protocol 108 traffic, ESP/IKE activity from untrusted sources, or repeated malformed/compression-related IPsec traffic to exposed gateways. There are no public, unique attacker toolmarks or stable exploit strings for this issue based on the supplied data, so detection should focus on behavioral evidence of repeated IPComp error triggering and denial-of-service symptoms.

• IP protocol 108
• ipcomp
• IPComp
• xfrm
• XFRM
• Out of memory
• oom-killer
• Memory allocation failure
• page allocation failure
• soft lockup
• NETDEV WATCHDOG
• ip xfrm state
• ip xfrm policy

What your security team should do

• Inventory Linux servers, VPN gateways, routers, firewalls, and appliances that use IPsec/XFRM, especially where IPComp is enabled.
• Prioritize patching internet-facing, high-availability, or network-edge systems that terminate IPsec tunnels.
• Upgrade to the vendor-provided fixed kernel or firmware and reboot to ensure the patched kernel is active.
• Disable IPComp unless there is a clear operational requirement for IPsec compression.
• Restrict IPsec peer access with firewall rules, allowlists, and strong authentication to reduce the ability to reach vulnerable code paths.
• Add monitoring for abnormal kernel memory growth, OOM events, IPsec/XFRM errors, and sudden VPN service degradation.
• Because this is not currently in KEV and has low EPSS, track it through standard vulnerability management unless local exposure is high or IPComp is widely used.