CVE-2026-64523 Fixed in Linux 6.12.93, 7.0.12 and 7.1

The defect is not in Windows, Windows networking, or the ordinary TLS stacks used by browsers and applications. It affects Linux systems that have the kernel’s generic-netlink TLS handshake service built and that actually use an in-kernel consumer of that service. For Windows administrators, the relevant exposure is a Linux guest, appliance, container host, or WSL 2 instance running a custom or vendor-supplied Linux kernel—not the Windows host kernel.

The important wrinkle is that the CVE’s title, “net/handshake: Take a long-lived file reference at submit,” describes only one step in a larger repair series. The upstream commit message explicitly says the accept-side code had not yet been switched to use the newly pinned reference; that work arrives in the following patch. The stable releases identified by the Linux CVE team contain the integrated fixes, which is why their advice against isolated cherry-picks deserves particular attention here.

The bug is a socket lifetime race, not a TLS cipher flaw​

Linux’s

facility lets an in-kernel client submit a TLS handshake request for a user-space handler to process. The request travels through generic netlink, and a handler later accepts the request and works with the underlying socket. That division is useful for kernel services that need TLS but do not want a complete TLS handshake implementation embedded in every kernel consumer.

The flaw appears in the handoff between those stages. The request retained a reference to

, using

, but the file object and

were governed by a different reference count. If the client cancelled the handshake and released its final file-descriptor reference at precisely the wrong moment, Linux could tear down the

even though

remained alive.

That leaves the accept path with two bad outcomes described in the accompanying upstream fixes: it can follow a now-null socket pointer, or it can dereference memory that has already been freed. In practical terms, this is a kernel memory-safety failure caused by mismatched ownership rules, triggered during cancellation and teardown rather than during routine TLS traffic.

The fix adds an

member to the handshake request and acquires an explicit reference to

when the request is submitted. Completion and cancellation paths then release that reference exactly once, using the existing completion-state bit to decide which path owns cleanup. That turns the file reference into the request’s lifetime anchor instead of assuming a socket reference also protects the socket’s file object.

The CVE record and the patch series tell a fuller story​

The Linux CVE announcement dated July 25, 2026 names three affected files:

,

, and

. It identifies the original upstream fix as commit

, with stable backports in the 6.12 and 7.0 series.

But the upstream networking tree shows this was merged as part of a broader eight-patch branch titled “anchor request lifetime to a pinned file reference.” The series did more than add

:

• It changed the accept-side handler to use the pinned file reference rather than revisit req->hr_sk->sk_socket->file.
• It handed an additional file reference to the accept handler under lock, preventing a concurrent cancel path from withdrawing the reference before the handler could use it.
• It removed the now-redundant sock_hold() and sock_put() pairing, closing a separate submit-side race.
• It added KUnit checks that verify file-reference balances through successful submissions, errors, cancellation, and destruction paths.
• It repaired net-namespace teardown handling for pending handshake requests.

This changes the operational reading of CVE-2026-64523. The named commit fixes the request’s long-lived ownership gap, but it acknowledges that the accept path still dereferenced the old location until the next patch. Applying only the CVE’s original commit can therefore leave the vulnerable access pattern in place or create an incomplete ownership contract. The Linux kernel CVE team’s own mitigation language says individual commits are not tested alone and recommends moving to a current stable release.

That is the actionable conclusion: treat 6.12.93, 7.0.12, and 7.1 as the repair targets, not 09dba37eee70 as a standalone patch recipe.

“Critical” is an assigned score, not evidence of broad remote exposure​

The NVD entry currently carries no NVD-generated CVSS assessment, while displaying a CVSS 3.1 score of 9.8 Critical supplied by the Linux kernel CNA. That vector assumes network reachability, no privileges, no user interaction, and complete confidentiality, integrity, and availability impact.

The source code context supports the seriousness of a use-after-free or null-dereference condition inside the kernel, but it also exposes a limitation in reading the numeric score as a deployment verdict. This is not a bug reached merely by sending malformed TLS packets to a typical Linux web server. It depends on the relatively specialized

path, a participating in-kernel consumer, a user-space handshake handler, and a cancellation race during socket teardown.

The upstream discussion specifically names paths involving

,

, and

. Those details point to services using kernel-mediated TLS handshakes, including work around RPC and server-side transport handling, rather than the common OpenSSL- or GnuTLS-backed application model.

The Linux CVE announcement does not document public exploitation or provide a proof-of-concept. That absence does not make the bug harmless—kernel lifetime bugs warrant prompt patching—but it does mean organizations should distinguish between “affected source code exists in the kernel” and “this host runs a reachable service configuration that exercises it.”

WSL 2 and Windows fleets need a kernel inventory, not a Windows patch​

Microsoft documents that WSL 2 boots a Linux kernel inside its lightweight utility VM and allows an administrator to replace the Microsoft-provided default with a custom kernel through

. That is the dividing line for this advisory.

A normal Windows Update assessment will not tell an administrator whether a custom WSL kernel is at 6.12.92, 7.0.11, or another affected build. Nor does the Linux distribution’s package version necessarily answer the question, because WSL 2’s running kernel is separate from the distribution’s installed user-space packages. Check the live kernel from inside each WSL 2 environment:

For WSL fleets, also inspect

for a

setting. Microsoft’s WSL documentation confirms that setting applies globally across WSL 2 distributions, so one custom kernel image can affect every WSL 2 distro launched by that Windows profile. A kernel replacement requires restarting the WSL virtual machine;

is Microsoft’s documented fast path for that restart.

A version alone still does not establish practical exposure. The handshake subsystem must be present in the kernel configuration and an applicable in-kernel TLS handshake consumer must be active. But if a custom WSL kernel falls in the affected range, it should be updated as part of normal Linux kernel maintenance rather than dismissed because the workload happens to run on a Windows desktop or Windows Server host.

What administrators should do now​

For native Linux servers, appliances, and virtual machines, update through the distribution’s supported kernel channel and reboot into the installed kernel. Where a vendor backports the fix without changing to one of the exact upstream version numbers, validate the vendor advisory and its included patch set rather than relying on version-string comparisons alone.

For teams maintaining custom kernels, do not pull only the commit named in the CVE notice. Bring in the complete, dependency-aware stable update or confirm that the complete

file-reference series—including the accept-side handoff and the removal of the late

logic—is present in the tree.

The immediate operational consequence is straightforward: systems on Linux 6.12 before 6.12.93, Linux 7.0 before 7.0.12, or pre-7.1 development trees need a kernel update if they carry this subsystem. For Windows shops, the work is to identify WSL 2 custom kernels and Linux workloads under their management; the Windows host itself is outside CVE-2026-64523’s affected code path.