CVE-2026-23414

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]

• linux linux kernel (>= 6.1.158 < 6.1.168) • linux linux kernel (>= 6.6.114 < 6.6.131) • linux linux kernel (>= 6.12.55 < 6.12.80) • linux linux kernel (>= 6.17.5 < 6.18) • linux linux kernel (>= 6.18.1 < 6.18.21) • linux linux kernel (>= 6.19 < 6.19.11) • linux linux kernel 6.18 • linux linux kernel 7.0