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.
Security readout for executives and security teams
Plain-English summary
A Linux kernel flaw can mishandle repeated cancellation of the same network handshake, causing a socket reference-count underflow. The bundle rates it critical at CVSS 9.8. Systems using affected kernels and kernel TLS handshakes, particularly SUNRPC AUTH_TLS with tlshd, deserve urgent review. The supplied evidence does not establish real-world exploitation.
Executive priority
Treat as an urgent patch-validation issue for affected Linux infrastructure, especially systems using SUNRPC over TLS. Prioritize internet- or untrusted-network-facing hosts, but avoid assuming compromise: the bundle provides no evidence of active exploitation, and exact distribution exposure requires vendor mapping.
Technical view
A cancelled handshake leaves an entry in handshake_rhashtbl after removal from hn_requests. A second cancellation can bypass remove_pending() and release the socket reference again unless the request is marked completed, causing refcount underflow. The fix atomically sets HANDSHAKE_F_REQ_COMPLETED so duplicate cancellations are detected.
Likely exposure
Exposure is most plausible on systems running an affected Linux kernel and exercising the kernel handshake path, including SUNRPC AUTH_TLS operations involving tlshd. The bundle lists 6.4, 6.6.120, 6.12.64, 6.18.3, and 6.19 as affected entries, but does not clearly define complete version ranges or distribution package mappings.
Exploitation context
The CVSS vector describes network reachability without privileges or user interaction. The documented trigger involves duplicate cancellations, such as client and server timeouts during an incomplete AUTH_TLS handshake. KEV is false, and no supplied source states that exploitation is active or that a public exploit exists.
Researcher notes
The demonstrated defect is a race or repeated-state handling failure in cancellation logic. The supplied description establishes socket refcount underflow but does not prove confidentiality or integrity impact despite the CVSS ratings. Validate backports by checking for atomic completion marking in the pending-cancel path, using the referenced stable commits as authoritative anchors.
Mitigation direction
Prioritize vendor-supported kernel updates containing the referenced stable fixes.
Check distribution advisories for package-specific affected and corrected versions.
Review SUNRPC AUTH_TLS and tlshd deployments for heightened exposure.
If immediate patching is impossible, consult vendor guidance for supported temporary mitigations.
Validation and detection
Record running kernel versions across exposed Linux systems.
Map distribution packages to the referenced upstream stable commits.
Identify hosts using SUNRPC AUTH_TLS, kernel TLS handshakes, or tlshd.
After updating, confirm the active kernel contains the applicable fix.
Monitor kernel logs for handshake failures, refcount warnings, or related crashes.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-68775 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
5Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.