CVE Catalog

CVE-2026-23414

HighCVSS 7.5
Published: Updated: Translated: NVD NIST

Exploitation Probability (EPSS)

Low risk
0.24%

15th percentile - higher than 15% of all known CVEs

Summary

A memory leak was found in the Linux kernel's TLS module related to the async_hold queue. The tls_decrypt_async_wait() function did not purge this queue, causing skb buffers to be retained after AEAD operations completed. The patch moves the purge operation into this function, centralizing management and preventing leaks.

Risk Assessment

Memory exhaustion could lead to system resource depletion, potentially causing a denial of service (DoS) under heavy TLS traffic.

Recommendation

Immediately update the Linux kernel to a version containing this fix. Monitor your distribution for the patched kernel version and apply it after testing.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

In the Linux kernel, the following vulnerability has been resolved: tls: Purge async_hold in tls_decrypt_async_wait() The async_hold queue pins encrypted input skbs while the AEAD engine references their scatterlist data. Once tls_decrypt_async_wait() returns, every AEAD operation has completed and the engine no longer references those skbs, so they can be freed unconditionally. A subsequent patch adds batch async decryption to tls_sw_read_sock(), introducing a new call site that must drain pending AEAD operations and release held skbs. Move __skb_queue_purge(&ctx->async_hold) into tls_decrypt_async_wait() so the purge is centralized and every caller -- recvmsg's drain path, the -EBUSY fallback in tls_do_decryption(), and the new read_sock batch path -- releases held skbs on synchronization without each site managing the purge independently. This fixes a leak when tls_strp_msg_hold() fails part-way through, after having added some cloned skbs to the async_hold queue. tls_decrypt_sg() will then call tls_decrypt_async_wait() to process all pending decrypts, and drop back to synchronous mode, but tls_sw_recvmsg() only flushes the async_hold queue when one record has been processed in "fully-async" mode, which may not be the case here. [[email protected]: added leak comment]

Vulnerability data from NVD (NIST) · CISA KEV · EPSS