CVE-2026-64523

What it actually does

This is a Linux kernel use-after-free race in the net/handshake subsystem. The vulnerable path submits a handshake request while holding a reference to the underlying socket object, but not a long-lived reference to the file object that owns the socket. If the last file reference is released during a narrow race window between request selection and later file-descriptor preparation, the socket can be torn down while later code still expects it to be valid. Successful exploitation can result in kernel memory corruption, kernel crash, or potentially arbitrary code execution in kernel context, depending on kernel configuration, allocator behavior, and exploit reliability.

Why it matters to the business

A successful attack could compromise or crash Linux systems that expose the vulnerable kernel handshake functionality, causing service outages, data exposure, or full host takeover. Although this issue is not currently listed in CISA KEV, is not reported as ransomware-used, has no known mature public exploit, and has a low EPSS score, the CVSS severity is critical because exploitation could occur without authentication or user interaction where the vulnerable path is reachable. Organizations should treat this as a high-priority kernel update, especially for internet-facing Linux services or systems using kernel TLS or related in-kernel handshake consumers.

How an attack unfolds

An attacker first needs to reach a code path that causes the Linux kernel net/handshake subsystem to create and submit a handshake request for a socket. The attacker then attempts to win a race where the request is accepted or processed while the file object backing the socket is concurrently released. Because the vulnerable implementation holds the socket but not the owning file reference, the final file release can call socket teardown while other handshake code still holds or later dereferences stale state. If the race is won, the kernel may dereference freed socket-related memory. In the simplest case this causes a kernel oops or panic and denial of service. With precise heap shaping and suitable kernel conditions, the memory corruption could potentially be steered toward privilege escalation or remote code execution in kernel context. Practical exploitability depends heavily on enabled kernel features, reachable protocol consumers, timing, kernel hardening, and memory allocator behavior.

How to fix it

Apply the vendor-provided Linux kernel update that includes the upstream fix for this net/handshake lifetime bug. The fix takes an explicit long-lived reference to the socket's backing file during handshake request submission and releases it on the serialized completion or cancellation path. No exact affected product list or fixed package versions were provided, so use distribution security advisories and kernel changelogs to identify the corrected kernel for each platform. Where immediate patching is not possible, reduce exposure by disabling or avoiding services/features that rely on the vulnerable in-kernel handshake path where operationally feasible, limiting network access to affected services, and increasing monitoring for kernel crashes or handshake-related faults. Reboot into the patched kernel after installation; merely installing the package is insufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm that systems are running a kernel version or vendor backport that contains the net/handshake fix adding a persistent file reference for handshake requests. On source-based or internally built kernels, verify that struct handshake_req includes a file-reference field such as hr_file and that handshake_req_submit() acquires a reference to sock->file while completion/cancellation paths release it using the same request-completion serialization. For packaged distributions, compare the running kernel reported by uname -r with the vendor advisory's fixed kernel package, and verify after reboot that the active kernel is the patched one. To assess exposure, confirm whether the kernel includes the affected net/handshake functionality and whether services that can invoke in-kernel handshake consumers are enabled or reachable.

Typical attack path

1. Identify a Linux system running a kernel build with the vulnerable net/handshake implementation and a reachable consumer of that subsystem.
2. Trigger creation of handshake requests against sockets handled by the affected kernel path.
3. Induce or race socket/file teardown while the handshake request is between request retrieval and file-reference acquisition.
4. Cause the handshake accept/completion/cancel path to operate on stale socket-related memory.
5. Leverage the resulting use-after-free to crash the kernel or, with additional exploitation primitives, corrupt kernel memory for code execution or privilege escalation.

How to detect it

There is no single reliable network indicator for prior exploitation because this is a kernel memory-lifetime bug and exploitation may leave only crash or instability artifacts. Review kernel logs, system journals, crash dumps, and EDR telemetry for oops, panic, KASAN, use-after-free, slab corruption, or general protection fault messages involving the net/handshake subsystem. Useful log sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/crash, kdump/vmcore repositories, hypervisor reset events, and host availability monitoring. Pay particular attention to repeated crashes under network load, crashes shortly after handshake-related service activity, or call traces mentioning handshake_nl_accept_doit(), handshake_req_next(), handshake_req_submit(), handshake_complete(), handshake_req_cancel(), FD_PREPARE(), sock_release(), or fput(). If crash dumps are available, inspect whether freed socket or file objects are referenced from handshake request structures. Absence of these artifacts does not prove non-exploitation, especially if kernel logs rotate or crash dumps are disabled.

• BUG: KASAN: use-after-free
• use-after-free in handshake_nl_accept_doit
• handshake_nl_accept_doit
• handshake_req_next
• handshake_req_submit
• handshake_complete
• handshake_req_cancel
• FD_PREPARE
• sock_release
• fput
• general protection fault
• kernel BUG at net/handshake
• Oops:
• Kernel panic - not syncing
• slab-use-after-free
• /var/log/kern.log
• /var/log/messages
• /var/crash
• vmcore

What your security team should do

• Prioritize patching Linux kernels on internet-facing servers, systems terminating encrypted or handshake-heavy network services, and multi-tenant hosts.
• Track distribution advisories for exact fixed kernel package versions and ensure systems reboot into the fixed kernel after deployment.
• If patching must be delayed, restrict network access to services that may trigger kernel handshake functionality and reduce unnecessary exposure.
• Enable centralized collection of kernel logs, crash dumps, and oops/panic events for rapid detection of attempted exploitation or stability issues.
• Review recent kernel crashes for use-after-free, general protection fault, KASAN, or call traces involving net/handshake functions.
• Because there is no KEV listing, no ransomware association, low EPSS, and no reported mature exploit, balance urgency with operational kernel patch testing, but do not defer beyond normal critical-kernel remediation timelines.