CVE-2026-63979

What it actually does

This is a Linux kernel use-after-free race in the net/handshake subsystem. A handshake request can be removed from the pending list and processed while another thread cancels the same handshake and releases the associated socket file reference. Because the accept path previously dereferenced the socket and file through req->hr_sk->sk_socket->file after dropping the handshake lock, it could read a NULL socket pointer or access freed struct socket / file memory. Successful exploitation could lead to kernel memory corruption, kernel crash, or potentially arbitrary code execution in kernel context, depending on allocator state, kernel configuration, and exploit reliability.

Why it matters to the business

Systems running affected Linux kernels may be exposed to a high-severity kernel memory-safety flaw that can cause service outages and, in a worst case, full system compromise. Because the issue is in kernel networking code, affected servers that use kernel TLS or RPC/TLS-style handshake functionality may be at elevated operational risk. There is currently no CISA KEV listing, no ransomware association, and low EPSS, which suggests no confirmed broad exploitation at this time; however, the CVSS severity is high and kernel-level impact warrants prompt patch planning, especially for internet-facing or high-availability Linux systems.

How an attack unfolds

An attacker would need to trigger handshake activity involving the vulnerable Linux kernel net/handshake path and cause a timing race between acceptance of a pending handshake request and cancellation/release of the underlying socket file. In the vulnerable sequence, handshake_req_next() removes a request from the pending list and drops hn_lock before handshake_nl_accept_doit() dereferences the request's socket file. If a concurrent cancellation path such as tls_handshake_cancel() followed by sockfd_put() or __fput_sync() releases the file and socket in that interval, sock_release() can orphan the socket and clear sk_socket. The accept side may then dereference NULL or freed memory. A reliable exploit would repeatedly force this race, shape kernel heap reuse, and attempt to convert the use-after-free into controlled memory corruption. More commonly, failed attempts may produce kernel warnings, KASAN reports, oopses, or crashes involving net/handshake, TLS handshake cancellation, or socket release routines.

How to fix it

Upgrade to a Linux kernel version that contains the fix for this vulnerability. The corrected implementation retargets accept-side dereferences to the pinned request file reference and hands off an additional file reference under hn_lock so concurrent cancellation cannot revoke it before FD_PREPARE() consumes it. If vendor fixed versions are not yet listed for a distribution, track the advisory from the relevant Linux distribution or kernel supplier and apply the first available security update containing the net/handshake fix. Where immediate patching is not possible, reduce exposure by disabling or avoiding kernel features and services that rely on the affected net/handshake/TLS handshake paths where operationally feasible, limiting network access to services that exercise these paths, and prioritizing kernel live patching or maintenance windows for high-risk systems. Reboot into the patched kernel after installation unless a verified live patch is used.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated. Validate with commands such as uname -a, package-manager kernel inventory, and vendor advisory mapping to ensure the active kernel includes the net/handshake file-reference handoff fix. Review distribution changelogs for references to net/handshake, handshake_req_next(), handshake_nl_accept_doit(), FD_PREPARE(), or use-after-free fixes. On test systems, run vendor or upstream regression tests if available, including handshake cancellation/acceptance race tests. Confirm that affected services operate normally after reboot and that kernel logs no longer show oops, KASAN, NULL pointer dereference, or use-after-free messages involving net/handshake or TLS handshake cancellation paths.

Typical attack path

1. Identify a Linux system running a vulnerable kernel with net/handshake functionality reachable through relevant networking workflows.
2. Trigger creation of kernel handshake requests, such as TLS-related handshake activity handled through the vulnerable subsystem.
3. Concurrently cause the associated handshake to be cancelled or the socket/file descriptor to be released while the accept path is processing the request.
4. Win the race after handshake_req_next() drops hn_lock but before handshake_nl_accept_doit() safely owns a valid file reference.
5. Cause the accept path to dereference a NULL or freed socket/file pointer.
6. Leverage the resulting use-after-free for denial of service or, with advanced heap grooming and kernel exploitation techniques, potential privilege escalation or kernel code execution.

How to detect it

Look for evidence of exploitation attempts or instability in kernel and system logs rather than application logs alone. Relevant sources include dmesg, journald, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore records, kernel oops reports, KASAN/KFENCE reports, audit logs, and EDR telemetry that captures kernel panics or abnormal reboots. Search for NULL pointer dereferences, general protection faults, use-after-free reports, refcount/file-count warnings, or call traces containing net/handshake functions and socket release paths. Pay particular attention to crashes or warnings occurring during TLS handshake activity, connection churn, service restarts, or RPC/NFS-over-TLS operations. There are no public reports of exploitation or named threat actors in the provided intelligence, so detection should focus on anomalous kernel faults matching the vulnerable code path and repeated attempts to induce handshake cancellation races.

• handshake_nl_accept_doit
• handshake_req_next
• handshake_req_cancel
• tls_handshake_cancel
• sockfd_put
• __fput_sync
• sock_release
• sock_orphan
• req->hr_sk->sk_socket
• req->hr_file
• FD_PREPARE
• net/handshake
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• BUG: unable to handle kernel NULL pointer dereference
• general protection fault
• kernel NULL pointer dereference
• use-after-free in handshake_nl_accept_doit
• use-after-free in handshake_req_next
• Call Trace: handshake_nl_accept_doit
• Call Trace: handshake_req_next
• Call Trace: tls_handshake_cancel
• Call Trace: sock_release
• Call Trace: __fput_sync

What your security team should do

• Inventory Linux systems and appliances running kernels that include the net/handshake subsystem, prioritizing internet-facing servers, TLS-heavy workloads, RPC/NFS-over-TLS deployments, and high-availability infrastructure.
• Monitor Linux distribution advisories and apply the fixed kernel as soon as available; because this is a kernel memory-corruption issue with CVSS 9.8, treat it as urgent even though it is not currently listed in KEV.
• Reboot systems into the patched kernel or verify live-patch coverage; do not rely on package installation alone.
• Enable and monitor kernel crash, oops, audit, and centralized syslog collection for signs of race-triggered crashes or memory-safety violations involving handshake_nl_accept_doit(), handshake_req_next(), tls_handshake_cancel(), sock_release(), or __fput_sync().
• Where patching is delayed, restrict network exposure to services likely to exercise kernel TLS or handshake functionality and consider temporarily disabling nonessential features dependent on the affected path.
• For high-risk fleets, add SIEM detections for kernel oops/KASAN patterns associated with this flaw and investigate unexplained kernel crashes as potential exploitation attempts.
• Track EPSS and threat intelligence changes; if exploit code or KEV listing appears, accelerate remediation to emergency timelines.