CVE-2025-38571

What it actually does

The sunrpc client-side TLS alert handling in tls_alert_recv assumes valid data exists in the msghdr iterator's kvec without ensuring a control message structure is initialized; sock_recvmsg can advance the kvec pointer during copy, causing the iterator to point to invalid memory when kTLS encounters a control record and returns an error.

Why it matters to the business

Organizations running NFS over TLS on affected Linux kernels face risk of client crashes or failed TLS sessions that disrupt file sharing and storage workloads; the low EPSS and absence from KEV indicate limited observed exploitation but kernel-level impact still warrants prompt patching across fleets.

How an attack unfolds

An attacker positioned to influence TLS records sent to an NFS client (for example via a malicious or compromised server) triggers kTLS to deliver a control message; because no control buffer was pre-allocated, the iterator state is invalid when tls_alert_recv runs, allowing the attacker to induce kernel memory corruption or denial of service during alert processing.

How to fix it

Upgrade the Linux kernel to commit a55b3d15331859d9fdd261cfa6d34ca2aeb0fb95 or later; for Chainguard packages apply openjdk-21-openj9 0.53.0-r0 or newer; rebuild and reboot affected systems; disable NFS over TLS temporarily if patching is delayed.

How to confirm the fix worked

Confirm the running kernel contains commit a55b3d15331859d9fdd261cfa6d34ca2aeb0fb95; verify that tls_alert_recv now receives a properly initialized control buffer before processing kTLS alerts; test NFS/TLS mounts with deliberate alert injection to ensure no crash occurs.

Typical attack path

1. Establish or hijack an NFS/TLS connection to the victim client
2. Send a TLS alert record that kTLS will treat as a control message
3. Force sock_recvmsg to return without a properly initialized control kvec
4. Trigger tls_alert_recv on the now-invalid iterator state
5. Cause kernel panic, memory corruption, or connection abort

How to detect it

Review kernel logs for sunrpc or kTLS related oops/panic messages around NFS/TLS sessions; look for unexpected TLS alert processing errors in dmesg or audit logs; correlate with NFS client connection resets or mount failures that coincide with TLS control records.

What your security team should do

• Prioritize kernel upgrades on all systems using NFS over TLS within the next maintenance window
• Add the fixed commit hash to patch-management and image-scanning policies
• Monitor EPSS trend for any further increase and re-evaluate if new exploit code appears
• Temporarily restrict NFS/TLS exposure for high-risk workloads until patches are deployed