CVE-2026-23414: Linux Kernel TLS Memory Leak Vulnerability

CVE-2026-23414 Overview

CVE-2026-23414 is a memory leak vulnerability in the Linux kernel's TLS (Transport Layer Security) subsystem. The flaw exists in the tls_decrypt_async_wait() function, which fails to properly purge the async_hold queue containing encrypted input socket buffers (skbs) when asynchronous AEAD (Authenticated Encryption with Associated Data) decryption operations complete.

The async_hold queue pins encrypted input skbs while the AEAD engine references their scatterlist data. When tls_decrypt_async_wait() returns, all AEAD operations have completed, but the held skbs may not be freed in certain failure scenarios. Specifically, when tls_strp_msg_hold() fails partway through after adding cloned skbs to the async_hold queue, the system drops back to synchronous mode without properly flushing the queue, resulting in a memory leak.

Critical Impact

Repeated exploitation of this memory leak can lead to kernel memory exhaustion, potentially causing system instability or denial of service on systems using kernel TLS for encrypted network communications.

Affected Products

• Linux kernel with TLS software encryption support (tls_sw)
• Systems using kernel TLS (kTLS) for network encryption
• Applications utilizing TLS offload functionality

Discovery Timeline

• April 02, 2026 - CVE CVE-2026-23414 published to NVD
• April 02, 2026 - Last updated in NVD database

Technical Details for CVE-2026-23414

Vulnerability Analysis

This vulnerability represents a memory leak condition in the Linux kernel's TLS software implementation. The root of the issue lies in the handling of asynchronous decryption operations where multiple code paths interact with the async_hold queue.

The tls_sw_recvmsg() function only flushes the async_hold queue when a record has been processed in "fully-async" mode. However, when tls_strp_msg_hold() fails after partially populating the queue with cloned skbs, tls_decrypt_sg() calls tls_decrypt_async_wait() to process pending decrypts before falling back to synchronous mode. In this failure path, the held skbs are never released because the async mode flush condition isn't met.

The vulnerability affects three distinct code paths:

1. The recvmsg drain path
2. The -EBUSY fallback in tls_do_decryption()
3. The batch path introduced for tls_sw_read_sock()

Root Cause

The root cause is the decentralized management of the async_hold queue purge operation. Each call site that synchronizes with pending AEAD operations was responsible for independently managing the skb purge, leading to inconsistent cleanup behavior. The fix centralizes the __skb_queue_purge(&ctx->async_hold) call within tls_decrypt_async_wait() itself, ensuring that every synchronization point properly releases held skbs without requiring each caller to handle the purge.

Attack Vector

This vulnerability can be triggered locally by any process utilizing kernel TLS encryption. An attacker with the ability to establish TLS connections through the kernel's native TLS implementation could repeatedly trigger the failure condition in tls_strp_msg_hold(), causing progressive memory exhaustion. The attack requires:

1. Access to create sockets with kernel TLS enabled (SOL_TLS socket option)
2. The ability to trigger partial failures during async decryption batching
3. Sustained network activity to accumulate leaked memory over time

The vulnerability does not directly provide code execution capabilities, but the resulting resource exhaustion could be leveraged as part of a larger denial of service attack against the affected system.

Detection Methods for CVE-2026-23414

Indicators of Compromise

• Gradual increase in kernel memory consumption (slab allocations) on systems using kTLS
• Memory pressure warnings in system logs related to network buffer allocations
• Unexplained growth in sk_buff allocations visible through /proc/slabinfo

Detection Strategies

• Monitor kernel memory usage patterns, specifically tracking skbuff_head_cache and related slab caches for abnormal growth
• Implement alerts for systems where kTLS is enabled that show sustained memory consumption increases without corresponding application load
• Review system logs for TLS-related error messages indicating decryption failures or fallback to synchronous mode

Monitoring Recommendations

• Enable kernel memory leak detection tools such as kmemleak during testing and staging environments
• Deploy monitoring for /proc/meminfo focusing on Slab and SUnreclaim values on production systems using kTLS
• Configure alerting thresholds for memory consumption anomalies on network-intensive servers

How to Mitigate CVE-2026-23414

Immediate Actions Required

• Update to a patched Linux kernel version containing the fix commits
• Consider temporarily disabling kernel TLS (kTLS) and using userspace TLS implementations if patching is not immediately feasible
• Monitor affected systems for signs of memory exhaustion while awaiting patch deployment

Patch Information

The vulnerability has been resolved by centralizing the __skb_queue_purge(&ctx->async_hold) call into tls_decrypt_async_wait(). This ensures that all code paths properly release held skbs upon synchronization with pending AEAD operations.

Official patches are available through the Linux kernel stable tree:

• Kernel Git Commit 2dcf324
• Kernel Git Commit 6dc11e0
• Kernel Git Commit 84a8335
• Kernel Git Commit 9f557c7
• Kernel Git Commit fd8037e

Workarounds

• Disable kernel TLS by not setting SOL_TLS socket options at the application level, reverting to userspace TLS libraries such as OpenSSL
• Limit kernel TLS usage to trusted applications where the risk of triggering the leak condition is minimized
• Implement memory monitoring and automatic service restarts as a temporary mitigation until patches can be applied

# Check if kTLS is enabled on the system
cat /proc/sys/net/tls/enabled

# Verify current kernel version
uname -r

# Monitor slab cache for potential memory leaks
watch -n 5 'cat /proc/slabinfo | grep -E "skbuff|tls"'