CVE-2025-38471

What it actually does

Use-after-free in the Linux kernel TLS receive path (tls_strp_check_rcv) caused by stale skb references after aggressive TCP skb compaction; read of freed memory leads to KASAN-detected slab corruption with potential for local code execution or denial of service.

Why it matters to the business

Linux systems performing TLS operations face risk of crashes, instability, or local privilege escalation; high prevalence in server and container environments increases exposure for workloads relying on kernel TLS, with moderate urgency given low EPSS and no confirmed KEV or ransomware use.

How an attack unfolds

A local attacker with low privileges crafts or triggers TLS receive operations that exploit the stale skb queue state after TCP compaction; by racing socket reads with network activity the attacker causes the TLS stripper to dereference a freed skb, enabling memory corruption that can be turned into arbitrary code execution or kernel panic. Named threat actors associated with Linux kernel privilege-escalation campaigns have been observed targeting similar kernel flaws.

How to fix it

Update the Linux kernel to a build containing the fix that always refreshes the TLS receive queue (commit equivalent to 4eb0a532efe679917e07655721145c6882bdb4c7 in related trees); rebuild and reboot affected systems; where immediate patching is impossible, restrict untrusted local access and disable kernel TLS where feasible.

How to confirm the fix worked

Confirm the running kernel contains the queue-refresh change in net/tls/tls_strp.c; run regression tests exercising tls_sw_recvmsg under concurrent TCP compaction; verify absence of KASAN reports in tls_strp_check_rcv during stress workloads.

Typical attack path

1. Obtain local user access on a vulnerable Linux host
2. Trigger TLS socket receive paths while inducing TCP skb compaction
3. Force tls_strp_check_rcv to operate on a freed skb
4. Leverage resulting use-after-free for memory corruption or ROP
5. Escalate to root or cause targeted denial of service

How to detect it

Search kernel logs for KASAN reports referencing tls_strp_check_rcv, tls_rx_rec_wait, or tls_sw_recvmsg; inspect auditd or syscall logs for unusual local TLS socket activity preceding crashes; correlate with threat-actor TTPs involving Linux kernel privilege-escalation chains.

What your security team should do

• Prioritize kernel updates on all TLS-enabled Linux hosts within standard change windows
• Monitor EPSS trend and any new threat-actor reports for rapid re-evaluation
• Apply least-privilege controls to limit local attackers' ability to trigger the flaw
• Test kernel TLS workloads in staging before broad deployment of the fixed kernel