CVE-2026-23239: Linux Kernel Race Condition Vulnerability

CVE-2026-23239 Overview

A race condition vulnerability has been identified in the Linux kernel's espintcp (ESP-in-TCP encapsulation) subsystem. The flaw exists in the espintcp_close() function where improper synchronization between the socket close operation and the transmit work queue can lead to use-after-free conditions. This vulnerability was discovered during a code audit of the kernel's IPsec over TCP implementation.

Critical Impact
A race condition in espintcp_close() allows the espintcp_tx_work() worker to potentially dereference freed memory (espintcp ctx or sk structures), which could lead to kernel crashes, denial of service, or potentially privilege escalation.

Affected Products

Linux kernel with espintcp (ESP-in-TCP) functionality enabled
Systems using IPsec over TCP encapsulation
Kernel configurations with CONFIG_INET_ESPINTCP enabled

Discovery Timeline

2026-03-10 - CVE CVE-2026-23239 published to NVD
2026-03-11 - Last updated in NVD database

Technical Details for CVE-2026-23239

Vulnerability Analysis

The vulnerability is a classic race condition between socket cleanup and work queue scheduling in the espintcp subsystem. When espintcp_close() is invoked, it calls cancel_work_sync() to cancel any pending work associated with the espintcp context. However, after this cancellation completes, the work can still be rescheduled from asynchronous code paths such as the Delayed ACK handler or ksoftirqd.

This creates a Time-of-Check Time-of-Use (TOCTOU) window where the work queue item can be scheduled after cancellation but before the socket and context structures are completely torn down. When espintcp_tx_work() eventually executes, it attempts to access the espintcp context (ctx) or socket (sk) that may have already been freed, resulting in a use-after-free condition.

Root Cause

The root cause is the use of cancel_work_sync() which only cancels and waits for completion of currently scheduled work, but does not prevent future scheduling. The function espintcp_write_space() (which can be called from interrupt context via TCP callbacks) contains a schedule_work(&ctx->work) call that can race with the close operation.

The fix replaces cancel_work_sync() with disable_work_sync(), which not only cancels pending work but also prevents the work from being scheduled in the future, closing the race window entirely.

Attack Vector

The race condition can be triggered in the following scenario:

On CPU0, when a socket using espintcp is being closed, espintcp_close() calls cancel_work_sync(). Meanwhile on CPU1, the espintcp_write_space() callback is invoked (potentially from the Delayed ACK handler or ksoftirqd) which calls schedule_work(&ctx->work). Since cancel_work_sync() has already completed on CPU0, this new work scheduling succeeds. Subsequently, when the work executes, it accesses freed memory as the close operation has already cleaned up the socket and context structures.

An attacker with local access could potentially trigger this race condition by manipulating the timing of socket operations and network traffic to create conditions where the race window is exploitable.

Detection Methods for CVE-2026-23239

Indicators of Compromise

Kernel panic or oops messages referencing espintcp_tx_work or espintcp_close
Use-after-free warnings in kernel logs related to espintcp subsystem
Unexpected system crashes or freezes when using IPsec over TCP connections
KASAN (Kernel Address Sanitizer) reports indicating use-after-free in espintcp functions

Detection Strategies

Monitor kernel logs for oops or panic messages mentioning espintcp functions
Enable KASAN in development/testing environments to detect memory access violations
Implement system stability monitoring to detect unexpected kernel crashes
Review audit logs for suspicious patterns of IPsec connection establishment and teardown

Monitoring Recommendations

Deploy kernel crash dump analysis to identify espintcp-related failures
Configure alerting on kernel oops events containing espintcp references
Monitor system uptime metrics for unexpected restarts on systems using IPsec over TCP
Enable lockdep debugging to detect potential race conditions in kernel subsystems

How to Mitigate CVE-2026-23239

Immediate Actions Required

Update to a patched Linux kernel version containing the fix
If immediate patching is not possible, consider temporarily disabling espintcp functionality
Monitor systems using IPsec over TCP for signs of instability
Review kernel configurations and disable CONFIG_INET_ESPINTCP if the feature is not required

Patch Information

The Linux kernel development team has released patches to address this vulnerability. The fix replaces cancel_work_sync() with disable_work_sync() in the espintcp_close() function, ensuring that work cannot be rescheduled after the close operation begins.

Patches are available through the following kernel git commits:

Workarounds

Disable espintcp functionality by removing or blacklisting the kernel module if not required
Avoid using IPsec over TCP encapsulation until patching is complete
Implement network segmentation to limit exposure of systems requiring espintcp functionality
Consider using alternative IPsec encapsulation methods such as UDP encapsulation (NAT-T) where applicable

bash

# Check if espintcp module is loaded
lsmod | grep espintcp

# Temporarily disable espintcp (if modular)
modprobe -r esp4_tcp
modprobe -r esp6_tcp

# Prevent module from loading on boot
echo "blacklist esp4_tcp" >> /etc/modprobe.d/blacklist-espintcp.conf
echo "blacklist esp6_tcp" >> /etc/modprobe.d/blacklist-espintcp.conf