CVE Alert: CVE-2025-39682 – Linux

In the Linux kernel, the following vulnerability has been resolved: tls: fix handling of zero-length records on the rx_list Each recvmsg() call must process either – only contiguous DATA records (any number of them) – one non-DATA record If the record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don’t know type until decryption) we queue the pending record to the rx_list. recvmsg() will pick it up from there. Queuing the skb to rx_list after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don’t have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length). Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rx_list, and it’s zero length.

This is an urgent, remotely exploitable kernel flaw with active exploitation, capable of causing host compromise or repeated denial of service; treat as priority 1.

A network peer can trigger the condition without authentication or user interaction, potentially exposing kernel memory, corrupting kernel heap state, or crashing the host. The main business risks are service outages, compromise of systems handling protected traffic, and possible follow-on access to workloads or credentials on the affected host.

### Most likely attack path

With AV:N, AC:L, PR:N and UI:N, an attacker sends a deliberately ordered sequence of TLS records to a reachable kTLS socket; no race, special account or victim action is required. Scope is unchanged, but successful kernel corruption can still provide complete control of the host and enable lateral movement through its services, credentials or network position.

### Who is most exposed

Prioritise internet-facing Linux servers and appliances using kernel TLS, particularly TLS termination, high-throughput network services, and systems supporting encrypted NFS, SMB or RPC traffic. Linux clients initiating connections to untrusted or compromised TLS peers are also relevant.

Alert on kernel oopses, panics, slab corruption, double-free warnings or unexpected reboots.

Correlate unusual TLS connection bursts with malformed, empty or rapidly sequenced records.

Review kTLS usage and `recvmsg` activity on exposed services.

Check host and application logs for abrupt socket closures preceding crashes.

### Mitigation and prioritisation

Treat as priority 1; deploy the vendor or distribution kernel fix as an emergency change.

Identify kTLS-enabled workloads and temporarily disable kTLS where operationally safe.

Restrict untrusted access to affected TLS listeners using network controls and segmentation.

Reboot after kernel replacement and verify the running kernel, not merely installed packages.

A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.

If you like the site, please support us on Patreon or Buy Me A Coffee using the buttons below.