A defect in the Linux kernel's TLS subsystem prevents queued encrypted packets from being released after asynchronous decryption completes. The async_hold queue retains skbs until all cryptographic work finishes, but the purge was not centralized, causing some packets to remain allocated when the entire decryption path drops out to synchronous mode. This results in a memory leak that grows over time and can eventually exhaust system memory. The flaw is specific to the AEAD engine and is triggered by TLS traffic that exercises the asynchronous decryption path, so it can affect any network service that relies on TLS for inbound data. The impact is an increase in kernel heap usage and a high probability of a denial‑of‑service condition from memory exhaustion, though it does not provide privilege escalation or code execution.

Systems running the Linux kernel are affected. The vulnerable releases are those that contain the pre‑patch async_hold handling; specific kernel versions are not listed in the advisory, so all kernels that have not applied the described patch are at risk.

No CVSS or EPSS score is included in the advisory, and the vulnerability is not listed in CISA’s KEV catalog, indicating it is not a known exploited vulnerability. The flaw is local to the kernel TLS decrypt routine, so the likely attack vector is through crafted TLS traffic sent to a listening service that uses TLS. While the core payload just leaks memory, repeated exploitation could lead to a local or remote denial‑of‑service by exhausting memory resources.