tls: Purge async_hold in tls_decrypt_async_wait()
Summary
| CVE | CVE-2026-23414 |
| State | PUBLISHED |
| Assigner | Linux |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-04-02 12:16:20 UTC |
| Updated | 2026-04-02 12:16:20 UTC |
| Description | 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] |
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|
| CNA |
Linux |
Linux |
affected c61d4368197d65c4809d9271f3b85325a600586a 2dcf324855c34e7f934ce978aa19b645a8f3ee71 git |
Not specified |
| CNA |
Linux |
Linux |
affected 39dec4ea3daf77f684308576baf483b55ca7f160 6dc11e0bd0a5466bcc76d275c09e5537bd0597dd git |
Not specified |
| CNA |
Linux |
Linux |
affected b8a6ff84abbcbbc445463de58704686011edc8e1 9f557c7eae127b44d2e863917dc986a4b6cb1269 git |
Not specified |
| CNA |
Linux |
Linux |
affected b8a6ff84abbcbbc445463de58704686011edc8e1 fd8037e1f18ca5336934d0e0e7e1a4fe097e749d git |
Not specified |
| CNA |
Linux |
Linux |
affected b8a6ff84abbcbbc445463de58704686011edc8e1 84a8335d8300576f1b377ae24abca1d9f197807f git |
Not specified |
| CNA |
Linux |
Linux |
affected 9f83fd0c179e0f458e824e417f9d5ad53443f685 git |
Not specified |
| CNA |
Linux |
Linux |
affected 4fc109d0ab196bd943b7451276690fb6bb48c2e0 git |
Not specified |
| CNA |
Linux |
Linux |
affected 6.18 |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.18 semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.6.131 6.6.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.12.80 6.12.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.18.21 6.18.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.19.11 6.19.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 7.0-rc6 * original_commit_for_fix |
Not specified |
References
| Reference | Source | Link | Tags |
|---|
| git.kernel.org/stable/c/9f557c7eae127b44d2e863917dc986a4b6cb1269 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/6dc11e0bd0a5466bcc76d275c09e5537bd0597dd |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/fd8037e1f18ca5336934d0e0e7e1a4fe097e749d |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/84a8335d8300576f1b377ae24abca1d9f197807f |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/2dcf324855c34e7f934ce978aa19b645a8f3ee71 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| CVE Program record |
CVE.ORG |
www.cve.org |
canonical |
| NVD vulnerability detail |
NVD |
nvd.nist.gov |
canonical, analysis |
No vendor comments have been submitted for this CVE.
There are currently no legacy QID mappings associated with this CVE.