CVE-2026-23414: tls: Purge async_hold in tls_decrypt_async_wait()
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 tlsswreadsock(), 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]
Affected Software
Event History
Frequently Asked Questions
Which deployments are affected?
The affected software listed is the Linux kernel and Microsoft azl3 kernel 6.6.130.1-3. The issue is in the kernel TLS software receive/decryption path.
What conditions trigger the leak?
The leak can occur during asynchronous TLS decryption when tls_strp_msg_hold() fails after it has already placed some cloned skbs on the async_hold queue. Pending decryptions are synchronized, but the held skbs may not be flushed by the receive path.
What is the operational impact?
Encrypted input skbs can remain pinned after the AEAD engine has finished using them, causing a memory leak. The supplied severity vector rates the availability impact as high, with no confidentiality or integrity impact.
What does the resolved change do?
It centralizes purging of the async_hold queue in tls_decrypt_async_wait(), after all pending AEAD operations have completed. This ensures held skbs are released for the recvmsg drain path, the -EBUSY fallback, and the batch read_sock path.