Answer in brief
CVE-2026-23414 records a High severity (CVSS 7.5) vulnerability in tls: Purge async_hold in tls_decrypt_async_wait(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic), Siemens/SIMATIC S7-1500 CPU 1518-4 PN/DP MFP (generic), Siemens/SIMATIC S7-1500 CPU 1518-4 PN/DP MFP (generic) and additional mapped packages. Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
Answer in brief
CVE-2026-23414 records a High severity (CVSS 7.5) vulnerability in tls: Purge async_hold in tls_decrypt_async_wait(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic), Siemens/SIMATIC S7-1500 CPU 1518-4 PN/DP MFP (generic), Siemens/SIMATIC S7-1500 CPU 1518-4 PN/DP MFP (generic) and additional mapped packages. Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic), Siemens/SIMATIC S7-1500 CPU 1518-4 PN/DP MFP (generic), Siemens/SIMATIC S7-1500 CPU 1518-4 PN/DP MFP (generic) and additional mapped packages. Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=9f83fd0c179e0f458e824e417f9d5ad53443f685 <ac435be7c7613eb13a5a8ceb5182e10b50c9ce87 || >=c61d4368197d65c4809d9271f3b85325a600586a <2dcf324855c34e7f934ce978aa19b645a8f3ee71 || >=39dec4ea3daf77f684308576baf483b55ca7f160 <6dc11e0bd0a5466bcc76d275c09e5537bd0597dd || >=b8a6ff84abbcbbc445463de58704686011edc8e1 <9f557c7eae127b44d2e863917dc986a4b6cb1269 || >=b8a6ff84abbcbbc445463de58704686011edc8e1 <fd8037e1f18ca5336934d0e0e7e1a4fe097e749d || >=b8a6ff84abbcbbc445463de58704686011edc8e1 <84a8335d8300576f1b377ae24abca1d9f197807f || 4fc109d0ab196bd943b7451276690fb6bb48c2e0 || >=6.1.158 <6.1.168 || >=6.6.114 <6.6.131 || >=6.12.55 <6.12.80 || >=6.17.5 <6.18 | ac435be7c7613eb13a5a8ceb5182e10b50c9ce87, 2dcf324855c34e7f934ce978aa19b645a8f3ee71, 6dc11e0bd0a5466bcc76d275c09e5537bd0597dd, 9f557c7eae127b44d2e863917dc986a4b6cb1269, fd8037e1f18ca5336934d0e0e7e1a4fe097e749d, 84a8335d8300576f1b377ae24abca1d9f197807f, 6.1.168, 6.6.131, 6.12.80, 6.18 |
| Linux/Linuxgeneric | 6.18 | Not reported |
| Siemens/SIMATIC S7-1500 CPU 1518-4 PN/DP MFPgeneric | >=V3.1.6 <* | * |
| Siemens/SIMATIC S7-1500 CPU 1518-4 PN/DP MFPgeneric | >=V3.1.5 <* | * |
| Siemens/SIMATIC S7-1500 CPU 1518F-4 PN/DP MFPgeneric | >=V3.1.6 <* | * |
| Siemens/SIMATIC S7-1500 CPU 1518F-4 PN/DP MFPgeneric | >=V3.1.5 <* | * |
| Siemens/SIPLUS S7-1500 CPU 1518-4 PN/DP MFPgeneric | >=V3.1.6 <* | * |
| Siemens/SIPLUS S7-1500 CPU 1518-4 PN/DP MFPgeneric | >=V3.1.5 <* | * |
Published upstream
Apr 2, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Jul 14, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jul 14, 2026
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]
Quoted source text, attributed separately from HOL analysis.
CVSS is 7.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic), Siemens/SIMATIC S7-1500 CPU 1518-4 PN/DP MFP (generic), Siemens/SIMATIC S7-1500 CPU 1518-4 PN/DP MFP (generic) and additional mapped packages. Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=9f83fd0c179e0f458e824e417f9d5ad53443f685 <ac435be7c7613eb13a5a8ceb5182e10b50c9ce87 || >=c61d4368197d65c4809d9271f3b85325a600586a <2dcf324855c34e7f934ce978aa19b645a8f3ee71 || >=39dec4ea3daf77f684308576baf483b55ca7f160 <6dc11e0bd0a5466bcc76d275c09e5537bd0597dd || >=b8a6ff84abbcbbc445463de58704686011edc8e1 <9f557c7eae127b44d2e863917dc986a4b6cb1269 || >=b8a6ff84abbcbbc445463de58704686011edc8e1 <fd8037e1f18ca5336934d0e0e7e1a4fe097e749d || >=b8a6ff84abbcbbc445463de58704686011edc8e1 <84a8335d8300576f1b377ae24abca1d9f197807f || 4fc109d0ab196bd943b7451276690fb6bb48c2e0 || >=6.1.158 <6.1.168 || >=6.6.114 <6.6.131 || >=6.12.55 <6.12.80 || >=6.17.5 <6.18 | ac435be7c7613eb13a5a8ceb5182e10b50c9ce87, 2dcf324855c34e7f934ce978aa19b645a8f3ee71, 6dc11e0bd0a5466bcc76d275c09e5537bd0597dd, 9f557c7eae127b44d2e863917dc986a4b6cb1269, fd8037e1f18ca5336934d0e0e7e1a4fe097e749d, 84a8335d8300576f1b377ae24abca1d9f197807f, 6.1.168, 6.6.131, 6.12.80, 6.18 |
| Linux/Linuxgeneric | 6.18 | Not reported |
| Siemens/SIMATIC S7-1500 CPU 1518-4 PN/DP MFPgeneric | >=V3.1.6 <* | * |
| Siemens/SIMATIC S7-1500 CPU 1518-4 PN/DP MFPgeneric | >=V3.1.5 <* | * |
| Siemens/SIMATIC S7-1500 CPU 1518F-4 PN/DP MFPgeneric | >=V3.1.6 <* | * |
| Siemens/SIMATIC S7-1500 CPU 1518F-4 PN/DP MFPgeneric | >=V3.1.5 <* | * |
| Siemens/SIPLUS S7-1500 CPU 1518-4 PN/DP MFPgeneric | >=V3.1.6 <* | * |
| Siemens/SIPLUS S7-1500 CPU 1518-4 PN/DP MFPgeneric | >=V3.1.5 <* | * |
Published upstream
Apr 2, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Jul 14, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jul 14, 2026
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]
Quoted source text, attributed separately from HOL analysis.