CVE-2026-23414
Linux Kernel 6.1.158 – 6.1.168
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HSummary
CVE-2026-23414 is a high-severity Missing Release of Memory after Effective Lifetime (CWE-401) vulnerability in Linux Linux Kernel. Its CVSS base score is 7.5 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Endpoint Denial of Service (T1499); ranked at the 16th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-23414 is a memory leak vulnerability in the Linux kernel's TLS implementation, specifically affecting the software-based TLS decryption path. The issue arises in tls_decrypt_async_wait(), where the async_hold queue retains references to encrypted input socket kernel buffers (SKBs) during asynchronous AEAD operations. After decryption completes, these SKBs are not unconditionally freed due to improper purging of the queue, particularly in failure scenarios like partial failures in tls_strp_msg_hold() or when falling back from async to synchronous mode. This affects kernel versions prior to the application of the referenced stable patches.
Remote attackers can exploit this vulnerability over the network with low complexity and no privileges required. By triggering TLS decryption paths, such as through recvmsg or read_sock operations in fully-async or partial-async modes, an attacker can cause repeated memory leaks as cloned SKBs accumulate in the async_hold queue without being released. This leads to a high-impact denial of service via memory exhaustion, as indicated by the CVSS v3.1 score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and CWE-401 classification.
Mitigation requires updating to a patched Linux kernel version by applying the stable commits referenced in the advisory, including 2dcf324855c34e7f934ce978aa19b645a8f3ee71, 6dc11e0bd0a5466bcc76d275c09e5537bd0597dd, 84a8335d8300576f1b377ae24abca1d9f197807f, 9f557c7eae127b44d2e863917dc986a4b6cb1269, and ac435be7c7613eb13a5a8ceb5182e10b50c9ce87. These patches centralize the __skb_queue_purge(&ctx->async_hold) call in tls_decrypt_async_wait() to ensure all callers, including new batch async paths, properly drain pending operations and release held SKBs.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-18195
Vulnerability Data
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…
more
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]
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation (static analysis, fuzzing, or runtime leak detection) directly finds missing deallocation.
Requiring documented development standards and tools can mandate memory-management disciplines that avoid leaks at introduction.
Engineering principles applied during development can require explicit resource-release patterns that stop memory leaks from being coded.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly enforce proper memory allocation/deallocation via coding standards, reviews, and tooling.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development can detect unreleased memory, providing partial coverage of the weakness.
Secure development life cycle mandates memory-management practices that reduce missing-release defects.
Application security requirements can specify explicit memory-release rules, partially mitigating the weakness.
Secure system architecture and engineering principles include resource-management guidelines that address memory leaks.
Secure coding standards directly require proper allocation/deallocation, covering most of this weakness.
Capacity management may detect memory exhaustion symptoms but does not prevent the coding flaw.