CVE-2026-23414: Linux Kernel

Medium severity, CVSS 5.5. EPSS: 0.2% chance of exploitation in the next 30 days.

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. [pabeni@redhat.com: added leak comment]

Affected products

• Linux Linux Kernel: from 6.1.158, before 6.1.168 (fixed in 6.1.168); from 6.6.114, before 6.6.131 (fixed in 6.6.131); from 6.12.55, before 6.12.80 (fixed in 6.12.80); from 6.17.5, before 6.18 (fixed in 6.18); from 6.18.1, before 6.18.21 (fixed in 6.18.21); from 6.19, before 6.19.11 (fixed in 6.19.11); …

Published 2026-04-02. Last modified 2026-07-14.