CVE-2026-52974: Linux Kernel TLS Hardware Offload Memory Leak

Technical summary

CVE-2026-52974 is a resource leak in the Linux kernel's TLS receive-side hardware offload code path. When tls_set_device_offload_rx() fails during tls_dev_add(), the error handling calls tls_sw_free_resources_rx() to clean up the software TLS context previously initialized by tls_set_sw_offload(). However, tls_sw_free_resources_rx() calls tls_sw_release_resources_rx() (which stops the strparser) and tls_sw_free_ctx_rx() (which frees the context structure) without calling tls_strp_done(), which would free the anchor skb allocated by alloc_skb(0) in tls_strp_init(). The leak was introduced by commit 84c61fe1a75b, which replaced the standard strparser with a custom implementation that pre-allocates an anchor skb. The normal socket close path (tls_sk_proto_close() → tls_sw_strparser_done() → tls_strp_done()) correctly handles cleanup, but the failed-offload error path does not.

Business impact

This vulnerability poses a denial-of-service risk to systems that attempt TLS hardware offload in environments where offload initialization frequently fails (e.g., due to unsupported hardware, driver issues, or misconfiguration). Over time, repeated failed offload attempts will leak kernel memory, eventually exhausting available memory and causing system instability or crashes. On systems where TLS offload is not in use or where offload setup always succeeds, there is no practical impact. Servers handling high volumes of connection attempts that fail offload setup are at greatest risk.

Affected systems

All versions of the Linux kernel that include commit 84c61fe1a75b or later are affected. This commit introduced custom strparser logic for TLS receive-side processing. The vulnerability affects systems with TLS hardware offload capability (typically modern NICs supporting TLS offload) that attempt to enable this feature. Systems without TLS hardware offload support or those that do not attempt to offload TLS are not impacted. The fix requires a kernel update; no specific version numbers are provided in the advisory, so verify with your distribution or the Linux kernel community for patched releases.

Exploitability

This is not an exploitable vulnerability in the traditional sense; it cannot be leveraged to gain unauthorized access or execute arbitrary code. Instead, it is a denial-of-service vulnerability that requires an attacker or misconfiguration to repeatedly trigger failed TLS offload initialization. A local attacker could potentially exhaust kernel memory by repeatedly establishing and disconnecting TLS connections on a system with offload-enabled hardware, or a remote attacker could indirectly trigger the leak by sending connection attempts that cause offload setup to fail. The leak is deterministic—each failed offload leaks a fixed amount of memory—making the attack surface predictable but not easily exploitable from the network without application-level cooperation.

Remediation

Apply a kernel patch that adds proper cleanup of the anchor skb in the error path of tls_set_device_offload_rx(). The fix should ensure that tls_strp_done() is called (directly or indirectly) before freeing the TLS context during failed offload initialization, or by adding an explicit kfree_skb() call for the anchor skb in tls_sw_free_resources_rx(). Systems that do not use TLS hardware offload can reduce risk by disabling offload at compile time or runtime; however, this should only be done after patch availability is verified. Verify the specific patched kernel version against your distribution's security advisories.

Patch guidance

Monitor your Linux distribution's security bulletins and the Linux kernel stable tree for patches addressing CVE-2026-52974. When available, apply the patched kernel version to your systems. If your distribution has not yet released a patch, consider disabling TLS hardware offload if feasible (via module parameters or driver configuration) until a patch is available, especially on systems that experience frequent connection churn. Test patches in a staging environment first, as kernel updates may require reboot and can affect network performance if offload behavior changes.

Detection guidance

Monitor kernel memory usage patterns for unexplained growth, particularly on systems with TLS offload enabled. Enable kernel memory leak detectors (KMEMLEAK) in testing or staging environments to identify the leak. Check system logs for failed TLS offload initialization events (look for device offload setup failures). Tools like 'dmesg', 'free', and memory profilers can help track memory pressure over time. On systems with hardware offload enabled, establish a baseline of memory usage and alert on sustained increases that correlate with failed offload setup attempts.

Why prioritize this

Although the CVSS score is 7.5 (HIGH), this vulnerability should be prioritized based on your environment's use of TLS hardware offload and tolerance for service disruption. Organizations running high-traffic TLS services on systems with offload-capable hardware should patch quickly, as memory exhaustion can cause outages. Systems without offload support or where offload is disabled can deprioritize patching. For most organizations, this is a medium-to-high priority patch rather than critical, since exploitation requires sustained failed offload attempts and does not lead to confidentiality or integrity breaches.

Risk score, explained

The CVSS 3.1 score of 7.5 (HIGH) reflects a network-accessible availability impact (AV:N, AC:L, PR:N, UI:N, S:U, C:N, I:N, A:H). The score correctly captures that no authentication is required and the impact is denial of service via memory exhaustion. However, the real-world risk is moderated by the requirement that TLS offload be enabled and that offload setup fail repeatedly, which is not the default configuration on all systems. The severity is appropriate for environments where offload is actively used and failure rates are elevated.

Frequently asked questions