CVE-2025-68775
Description
In the Linux kernel, the following vulnerability has been resolved:
net/handshake: duplicate handshake cancellations leak socket
When a handshake request is cancelled it is removed from the handshake_net->hn_requests list, but it is still present in the handshake_rhashtbl until it is destroyed.
If a second cancellation request arrives for the same handshake request, then remove_pending() will return false... and assuming HANDSHAKE_F_REQ_COMPLETED isn't set in req->hr_flags, we'll continue processing through the out_true label, where we put another reference on the sock and a refcount underflow occurs.
This can happen for example if a handshake times out - particularly if the SUNRPC client sends the AUTH_TLS probe to the server but doesn't follow it up with the ClientHello due to a problem with tlshd. When the timeout is hit on the server, the server will send a FIN, which triggers a cancellation request via xs_reset_transport(). When the timeout is hit on the client, another cancellation request happens via xs_tls_handshake_sync().
Add a test_and_set_bit(HANDSHAKE_F_REQ_COMPLETED) in the pending cancel path so duplicate cancels can be detected.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Duplicate cancellation of a handshake request in the Linux kernel's net/handshake subsystem can trigger a socket refcount underflow, leading to use-after-free or a leak.
Root
Cause
The vulnerability resides in the net/handshake subsystem of the Linux kernel. When a handshake request is cancelled, it is removed from the handshake_net->hn_requests list but remains present in the handshake_rhashtbl until it is fully destroyed. If a second cancellation request arrives for the same request before it is removed from the rhashtbl, remove_pending() returns false. The code then continues through the out_true label without checking the HANDSHAKE_F_REQ_COMPLETED flag, resulting in an extra reference being put on the socket. This reference decrement causes a refcount underflow, which can corrupt memory and lead to use-after-free or other memory-safety issues [1].
Exploitation
Scenario
No special privileges are required to trigger this condition beyond the ability to initiate a TLS handshake (e.g., via SUNRPC with AUTH_TLS). The bug is exposed when multiple cancellation events race, such as when a server times out and sends a FIN (triggering a cancellation via xs_reset_transport()) at the same time the client times out (triggering a cancellation via xs_tls_handshake_sync()) [1]. An attacker who can cause handshake timeouts – for example, by blocking the tlshd daemon or delaying network responses – could potentially force this race condition.
Impact
The refcount underflow can cause a socket to be freed while still in use, leading to a use-after-free condition. This may allow an attacker to escalate privileges or cause a denial of service through memory corruption. The issue is specific to the kernel's handshake layer, which is used by TLS and other kernel-based transport security mechanisms.
Mitigation
Patches are available in the stable kernel trees. The fix adds a test_and_set_bit(HANDSHAKE_F_REQ_COMPLETED) check in the pending-cancel path so that duplicate cancellation requests are correctly detected and ignored [1]. System administrators should apply the latest stable kernel updates to remediate this vulnerability.
AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
1Patches
0No patches discovered yet.
Vulnerability mechanics
AI mechanics synthesis has not run for this CVE yet.
References
4News mentions
0No linked articles in our index yet.