PT-2026-29721 · Linux · Linux
Published
2026-04-02
·
Updated
2026-04-02
·
CVE-2026-23414
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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]
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux