Linux Kernel EUVD-2026-45752

Exploitation requires the target kernel to have the net/handshake upcall subsystem active with a userspace handshake agent servicing kTLS handshakes (typical of NFS/SunRPC or RDMA transports using tlshd), plus a consumer that cancels a handshake via tls_handshake_cancel() and releases the socket file (sockfd_put via svc_sock_free, or __fput_sync via xs_reset_transport). The attacker must win the race window between handshake_req_next() dropping hn_lock and handshake_nl_accept_doit() reaching FD_PREPARE(). Limiting factors: the handshake upcall path must be in use (non-default for hosts without kTLS consumers), local access to drive/cancel handshake requests is needed, and success is timing-dependent - contradicting the published AV:N/AC:L/PR:N vector, which is not supported by the described mechanism.

The signals conflict sharply. The published CVSS 3.1 is 9.8 (AV:N/AC:L/PR:N/UI:N, full C/I/A) implying trivial remote unauthenticated code execution, but the description and the Linux-reporter tag both point to a local race-condition use-after-free whose realistic outcome is a kernel crash (Denial of Service). EPSS agrees with the lower reading: 0.19% probability, 9th percentile, and there is no KEV entry and no known POC. The bug is only reachable on systems that actually use the kernel handshake upcall path (kTLS consumers such as NFS/SunRPC with a userspace handshake agent like tlshd running) and requires winning a narrow timing window between handshake_req_next() and FD_PREPARE(), so real-world exploitability is far below what 9.8 suggests. This should be treated as a genuine but low-urgency stability/DoS fix for most fleets, prioritized higher only where kTLS handshake upcalls are in active use. Explicit discrepancy to verify: CVSS advertises AV:N/AC:L/PR:N but the mechanism is a local, timing-dependent race requiring a cooperating/racing handshake consumer - the network vector and low complexity are not supported by the description.

On a host using kernel TLS handshake upcalls, an attacker (or an unlucky consumer under load) initiates a handshake and then, from a cooperating consumer path, runs tls_handshake_cancel() followed by sockfd_put()/__fput_sync() precisely while the netlink accept path is reading sock->file, freeing the struct socket in that window. The accept side then dereferences NULL or freed memory, crashing the kernel; no public POC is known, and the AC:L in the published vector understates the timing precision the race actually requires.