CVE-2026-52974

What it actually does

This is a Linux kernel memory leak in the network TLS receive path when TLS device offload setup fails. During RX offload initialization, the kernel allocates an internal socket buffer anchor for the TLS strparser. If the later device-offload registration step fails, the error cleanup path frees the software TLS context but does not free that anchor skb. Repeated failed kTLS RX offload setup attempts can therefore leak kernel memory. The practical technical impact is denial of service through gradual kernel memory exhaustion, not code execution or privilege escalation based on the available description.

Why it matters to the business

Systems using Linux kernel TLS with network device offload support may become unstable or unavailable if an attacker or untrusted local workload can repeatedly trigger failed TLS RX offload setup. The likely operational consequence is degraded networking, memory pressure, service crashes, or host reboot due to kernel memory exhaustion. EPSS is currently low, it is not listed in CISA KEV, and no public exploit maturity is reported, so this should be prioritized as a reliability and hardening update rather than an emergency internet-wide exploitation event.

How an attack unfolds

An attacker first needs a way to exercise the Linux kTLS receive offload setup path on a vulnerable kernel, typically from code running locally or from a workload that can create and configure TLS sockets using kernel TLS options. The attacker then repeatedly causes RX device offload setup to reach the point where the strparser anchor skb is allocated, but then fail during the device offload add operation. Each failed attempt leaves behind a small kernel socket-buffer allocation that is not released by the error path. By looping this behavior many times, the attacker can steadily consume kernel memory. If memory pressure becomes severe enough, the host may experience network failures, process termination by the OOM killer, service disruption, or a crash/reboot.

How to fix it

Apply a Linux kernel version or vendor backport that includes the fix for the net/tls RX offload cleanup path. Because no exact fixed versions were provided, use the relevant distribution or appliance vendor advisory to identify the corrected kernel package for each platform. Where immediate patching is not possible, reduce exposure by disabling or avoiding kTLS device RX offload where operationally feasible, restricting untrusted local code from configuring kernel TLS sockets, and limiting access to workloads that can exercise TLS offload features. Monitor systems with kernel TLS and capable NIC offload more closely until patched.

How to confirm the fix worked

Confirm that the running kernel package includes the vendor fix for the TLS RX offload cleanup path, not just that an updated package is installed. Validate with the distribution advisory, changelog, or kernel source/backport notes referencing the net/tls fix for freeing the strparser anchor skb on RX offload setup failure. After patching and rebooting into the fixed kernel, confirm the active kernel version with standard OS inventory tooling. If a safe lab reproduction is available, repeatedly trigger failed kTLS RX offload setup before and after the fix and compare kernel slab/socket-buffer memory behavior; the fixed kernel should not show unbounded growth attributable to failed setup attempts.

Typical attack path

1. Gain the ability to run code or control a workload that can create sockets and configure Linux kernel TLS options.
2. Create TLS sockets and request RX device offload on a vulnerable kernel and compatible network stack.
3. Force or rely on a failure in the device offload registration path after the TLS strparser anchor skb has been allocated.
4. Repeat the failed setup operation many times to accumulate unreleased kernel skb allocations.
5. Drive the system into kernel memory pressure, degraded network behavior, service instability, or denial of service.

How to detect it

There are no reliable file, registry, or network payload indicators for this issue because exploitation is primarily a kernel resource-exhaustion pattern. To assess possible prior exploitation, review system logs and telemetry for unexplained kernel memory pressure, OOM killer activity, host instability, or network service degradation correlated with processes repeatedly creating TLS sockets or configuring kTLS offload. Useful sources include kernel logs, journald/syslog, OOM reports, performance monitoring for slab/socket-buffer memory, eBPF or audit telemetry for repeated setsockopt activity involving SOL_TLS where available, NIC/TLS offload driver logs, and container runtime telemetry identifying workloads with unusual socket creation patterns. Look for sustained growth in skb-related slab allocations that does not return to baseline, especially around repeated failed TLS offload operations. Absence of these artifacts does not prove non-exploitation, because the leak may leave only transient resource-pressure evidence unless detailed kernel telemetry was collected.

• Out of memory: Killed process
• oom-killer
• invoked oom-killer
• Memory cgroup out of memory
• skbuff_head_cache
• SOL_TLS
• TLS_RX
• tls_set_device_offload_rx
• tls_dev_add
• tls_sw_free_resources_rx
• tls_strp_init

What your security team should do

• Inventory Linux systems using kernels with kTLS and NIC TLS offload capability, prioritizing externally exposed, multi-tenant, container-hosting, and high-availability systems.
• Patch affected Linux kernels through the appropriate OS or appliance vendor channel and reboot into the fixed kernel.
• If patching is delayed, disable kTLS device RX offload or avoid enabling TLS hardware offload where feasible until the fix is deployed.
• Restrict untrusted local workloads from using advanced socket options or kernel TLS features where container/runtime policy allows.
• Monitor kernel memory, skb/slab cache growth, OOM events, and unexplained network-service instability on systems that use TLS offload.
• Treat observed repeated failed TLS offload setup activity combined with growing kernel memory pressure as suspicious and investigate the originating process or workload.