CVE-2026-23414

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