In the Linux kernel, the following vulnerability has been resolved: tls: Purge asynchold in tlsdecryptasyncwait() The asynchold queue pins encrypted input skbs while the AEAD engine references their scatterlist data. Once tlsdecryptasyncwait() 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 tlsswread_sock(), introducing a new call site that must drain pending AEAD operations and release held skbs. Move _skbqueuepurge(&ctx->asynchold) into tlsdecryptasyncwait() so the purge is centralized and every caller -- recvmsg's drain path, the -EBUSY fallback in tlsdodecryption(), and the new readsock batch path -- releases held skbs on synchronization without each site managing the purge independently. This fixes a leak when tlsstrpmsghold() fails part-way through, after having added some cloned skbs to the asynchold queue. tlsdecryptsg() will then call tlsdecryptasyncwait() to process all pending decrypts, and drop back to synchronous mode, but tlsswrecvmsg() only flushes the asynchold queue when one record has been processed in "fully-async" mode, which may not be the case here. [pabeni@redhat.com: added leak comment]