GHSA-JPGQ-R68H-X9Q2

Vulnerability from github – Published: 2026-01-13 18:31 – Updated: 2026-01-13 18:31
VLAI?
Details

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.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-68775"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-13T16:15:57Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/handshake: duplicate handshake cancellations leak socket\n\nWhen a handshake request is cancelled it is removed from the\nhandshake_net-\u003ehn_requests list, but it is still present in the\nhandshake_rhashtbl until it is destroyed.\n\nIf a second cancellation request arrives for the same handshake request,\nthen remove_pending() will return false... and assuming\nHANDSHAKE_F_REQ_COMPLETED isn\u0027t set in req-\u003ehr_flags, we\u0027ll continue\nprocessing through the out_true label, where we put another reference on\nthe sock and a refcount underflow occurs.\n\nThis can happen for example if a handshake times out - particularly if\nthe SUNRPC client sends the AUTH_TLS probe to the server but doesn\u0027t\nfollow it up with the ClientHello due to a problem with tlshd.  When the\ntimeout is hit on the server, the server will send a FIN, which triggers\na cancellation request via xs_reset_transport().  When the timeout is\nhit on the client, another cancellation request happens via\nxs_tls_handshake_sync().\n\nAdd a test_and_set_bit(HANDSHAKE_F_REQ_COMPLETED) in the pending cancel\npath so duplicate cancels can be detected.",
  "id": "GHSA-jpgq-r68h-x9q2",
  "modified": "2026-01-13T18:31:03Z",
  "published": "2026-01-13T18:31:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68775"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/011ae80c49d9bfa5b4336f8bd387cd25c7593663"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/15564bd67e2975002f2a8e9defee33e321d3183f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3c330f1dee3cd92b57e19b9d21dc8ce5970b09be"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e1641177e7fb48a0a5a06658d4aab51da6656659"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.