CVE-2026-31518

What it actually does

This flaw is a Linux kernel denial-of-service issue in the IPsec ESP-in-TCP transmit path. When ESP-in-TCP is used with asynchronous crypto and the TCP transmit queue is full, the kernel error path can fail to release an sk_buff packet buffer. Repeatedly triggering this condition can leak kernel memory, eventually causing memory pressure, degraded networking, process failures, or a system crash. The issue affects availability only; it does not directly provide code execution, privilege escalation, or data disclosure.

Why it matters to the business

Successful exploitation can make affected Linux systems unstable or unavailable, especially systems using IPsec, VPN, or xfrm-based encrypted transport features. The practical risk is reduced by the local, low-privilege attack requirement, low EPSS score, no known public exploit maturity, and no CISA KEV listing, but exposed multi-user servers, VPN gateways, container hosts, and systems where untrusted users can run local workloads should still treat kernel availability issues seriously.

How an attack unfolds

An attacker first needs local access to an affected Linux system, such as a low-privileged shell, compromised application account, or untrusted workload. The attacker then attempts to generate traffic through an ESP-in-TCP IPsec path that uses asynchronous crypto while creating conditions where the TCP transmit queue becomes full. Under those conditions, the vulnerable kernel path returns an error without freeing the associated packet buffer. By repeatedly causing this failure path, the attacker can accumulate leaked sk_buff allocations in kernel memory. As unreclaimed memory grows, the system may experience high memory pressure, networking failures, service instability, out-of-memory kills, or a crash requiring reboot.

How to fix it

Upgrade the Linux kernel to a vendor-provided version that includes the fix for the ESP-in-TCP asynchronous crypto sk_buff leak. Because no exact fixed versions were provided, use the security advisory from the relevant Linux distribution or kernel vendor and confirm that the patch for "esp: fix skb leak with espintcp and async crypto" is included. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, disabling or avoiding ESP-in-TCP/IPsec configurations where feasible, avoiding asynchronous crypto offload paths if operationally acceptable, and monitoring systems that rely on xfrm/IPsec for unusual memory growth or network instability.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package/version against the distribution vendor advisory and ensuring the fix for the ESP-in-TCP asynchronous crypto skb leak is present. Validate that the host has rebooted into the patched kernel, not merely installed it. On systems using IPsec/xfrm, review whether ESP-in-TCP is enabled or required. Operationally validate by monitoring kernel memory/slab usage, network stability, and system logs under representative IPsec traffic; patched systems should not show sustained unreclaimed sk_buff growth or instability when ESP-in-TCP transmit queues are stressed.

Typical attack path

1. Obtain local low-privileged execution on an affected Linux host.
2. Identify or create traffic that uses the Linux xfrm/IPsec ESP-in-TCP path with asynchronous crypto.
3. Drive enough ESP-in-TCP transmission activity to fill or stress the TCP transmit queue.
4. Repeatedly trigger the vulnerable error path where packet buffers are not released.
5. Cause kernel memory pressure to accumulate over time.
6. Degrade or crash the host, resulting in denial of service.

How to detect it

There are no unique public exploit strings or network signatures for this issue. Detection should focus on signs of local abuse and resulting kernel memory exhaustion on systems using IPsec/xfrm, especially ESP-in-TCP. Review kernel logs, journald, syslog, audit logs, EDR telemetry, VPN/IPsec service logs, and host performance metrics. Look for unexplained growth in sk_buff or network-related slab allocations, sustained memory pressure, OOM killer activity, kernel soft lockups, network transmit queue errors, ESP/IPsec instability, unexpected service failures, or reboots. Correlate these symptoms with local user sessions, newly started processes, scripts, containers, or workloads that generated high volumes of IPsec/ESP-in-TCP traffic. Because exploitation requires local execution, authentication logs and process execution telemetry are important for identifying the initiating account or workload.

• Out of memory: Killed process
• oom-killer
• Memory allocation failure
• page allocation failure
• kernel: BUG: soft lockup
• kernel: INFO: task
• NETDEV WATCHDOG
• xfrm
• espintcp
• esp_output_tail_tcp
• esp_output_done
• skbuff_head_cache
• sk_buff
• /proc/slabinfo
• /proc/net/xfrm_stat
• /proc/net/xfrm_policy
• /proc/net/xfrm_state

What your security team should do

• Prioritize patching affected Linux systems that provide VPN, IPsec, xfrm, or encrypted tunnel functionality, and any multi-user or untrusted workload hosts.
• Confirm all patched systems have been rebooted into the fixed kernel.
• Inventory systems using ESP-in-TCP or xfrm/IPsec features to determine practical exposure.
• Restrict local access and untrusted workload execution on unpatched systems until remediation is complete.
• Monitor affected systems for memory pressure, abnormal sk_buff/slab growth, OOM events, soft lockups, networking errors, or unexpected reboots.
• Track vendor kernel advisories because fixed package versions vary by Linux distribution.
• Treat exploitation likelihood as currently low given no KEV listing, no known exploit maturity, and a very low EPSS score, but do not defer indefinitely on systems where availability is critical.