CVE-2026-23240: Linux Kernel TLS Race Condition Vulnerability

CVE-2026-23240 Overview

A race condition vulnerability has been identified in the Linux kernel's TLS (Transport Layer Security) subsystem, specifically within the tls_sw_cancel_work_tx() function. The flaw allows the tx_work_handler() worker to dereference a freed TLS object when cancel_delayed_work_sync() is called from tls_sk_proto_close(), while tx_work_handler() can still be scheduled from paths such as the Delayed ACK handler or ksoftirqd.

Critical Impact

This race condition can lead to use-after-free conditions where a TLS context object is dereferenced after being freed, potentially causing kernel crashes, denial of service, or memory corruption on affected Linux systems.

Affected Products

• Linux Kernel (TLS subsystem)
• Systems using kernel TLS offload functionality
• Servers and devices with TLS socket operations

Discovery Timeline

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

Technical Details for CVE-2026-23240

Vulnerability Analysis

This vulnerability is a classic time-of-check time-of-use (TOCTOU) race condition in the Linux kernel's TLS software implementation. The issue occurs during the cleanup path when a TLS socket is being closed. The tls_sk_proto_close() function calls tls_sw_cancel_work_tx() to cancel pending TX work, but a timing window exists where the work can be rescheduled after the cancellation attempt.

The race occurs between two concurrent operations: the socket close path on one CPU and the write space notification handler on another. When tls_write_space() triggers tls_sw_write_space(), it checks and sets the BIT_TX_SCHEDULED bit before scheduling work. However, this check can interleave with the close path's cancellation logic, allowing work to be scheduled after cancel_delayed_work_sync() completes but before the TLS context is freed.

Root Cause

The root cause is the use of cancel_delayed_work_sync() which only cancels currently pending work but does not prevent the work from being rescheduled. The atomic bit operation on BIT_TX_SCHEDULED and the work scheduling are not properly synchronized with the socket close path. This allows the delayed work to be scheduled after the cancellation, creating a window where tx_work_handler() can execute with a freed TLS context.

Attack Vector

The vulnerability manifests through a race between two kernel code paths:

1. cpu0 (Close Path):tls_sk_proto_close() → tls_sw_cancel_work_tx() → sets BIT_TX_SCHEDULED → calls cancel_delayed_work_sync()

2. cpu1 (Write Space Path):tls_write_space() → tls_sw_write_space() → checks BIT_TX_SCHEDULED → schedules delayed work

The race window occurs when cpu1's test_and_set_bit() check happens before cpu0's set_bit(), but the actual schedule_delayed_work() call on cpu1 executes after cpu0's cancel_delayed_work_sync() completes. This results in work being scheduled that will execute after the TLS context has been freed.

The fix replaces cancel_delayed_work_sync() with disable_delayed_work_sync(), which not only cancels pending work but also prevents the work from being rescheduled, closing the race window.

Detection Methods for CVE-2026-23240

Indicators of Compromise

• Kernel panic or oops messages referencing tx_work_handler or TLS-related functions
• Unexpected system crashes during high-volume TLS connection close operations
• KASAN (Kernel Address Sanitizer) reports indicating use-after-free in TLS subsystem
• Slab corruption warnings in kernel logs related to TLS socket contexts

Detection Strategies

• Monitor kernel logs for crash dumps mentioning tls_sw_cancel_work_tx, tx_work_handler, or related TLS functions
• Enable KASAN in debug builds to detect use-after-free memory access patterns
• Implement workqueue monitoring for anomalous delayed work scheduling patterns during socket cleanup
• Use kernel tracing (ftrace) to monitor TLS socket lifecycle events and detect race conditions

Monitoring Recommendations

• Deploy kernel crash dump analysis tools to capture and analyze any TLS-related panics
• Enable kernel memory debugging options (CONFIG_DEBUG_SLAB, CONFIG_KASAN) in development environments
• Monitor system stability metrics for unexplained crashes during periods of high TLS connection churn
• Implement automated kernel log parsing for TLS subsystem error signatures

How to Mitigate CVE-2026-23240

Immediate Actions Required

• Update to a patched Linux kernel version that includes the fix replacing cancel_delayed_work_sync() with disable_delayed_work_sync()
• Review systems with high TLS connection turnover for stability issues
• Consider temporarily reducing TLS socket connection rates on critical systems until patches are applied
• Monitor affected systems for kernel crashes or unexpected behavior

Patch Information

The vulnerability has been resolved through multiple kernel commits that replace cancel_delayed_work_sync() with disable_delayed_work_sync() in the TLS TX work cancellation path. The fix ensures that once work cancellation is initiated, the work cannot be rescheduled.

Patch commits are available:

• Kernel Git Commit 17153f154f80
• Kernel Git Commit 7bb09315f93d
• Kernel Git Commit 854cd32bc74f
• Kernel Git Commit a5de36d6cee7

Workarounds

• Reduce concurrent TLS socket operations where possible to minimize race condition likelihood
• Temporarily disable kernel TLS offload (setsockopt(SO_TLS)) if not critical to operations
• Implement connection rate limiting for applications with high TLS socket churn
• Schedule kernel upgrades as a priority for systems handling significant TLS traffic

# Check current kernel version
uname -r

# Verify if kernel TLS is in use
cat /proc/net/tls_stat

# Temporarily disable kernel TLS for new connections (application-level)
# Applications can avoid using SOL_TLS socket options until patched