{"resultsPerPage":1,"startIndex":0,"totalResults":1,"format":"NVD_CVE","version":"2.0","timestamp":"2026-04-18T21:50:25.931","vulnerabilities":[{"cve":{"id":"CVE-2025-68775","sourceIdentifier":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","published":"2026-01-13T16:15:57.073","lastModified":"2026-04-15T00:35:42.020","vulnStatus":"Deferred","cveTags":[],"descriptions":[{"lang":"en","value":"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->hn_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't set in req->hr_flags, we'll 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't\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."},{"lang":"es","value":"En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nnet/handshake: las cancelaciones duplicadas de handshake fugan el socket\n\nCuando una solicitud de handshake es cancelada, es eliminada de la lista handshake_net->hn_requests, pero aún está presente en la handshake_rhashtbl hasta que es destruida.\n\nSi llega una segunda solicitud de cancelación para la misma solicitud de handshake, entonces remove_pending() devolverá falso... y asumiendo que HANDSHAKE_F_REQ_COMPLETED no está establecido en req->hr_flags, continuaremos procesando a través de la etiqueta out_true, donde ponemos otra referencia en el sock y ocurre un desbordamiento negativo del contador de referencias.\n\nEsto puede ocurrir por ejemplo si un handshake agota el tiempo de espera, particularmente si el cliente SUNRPC envía la sonda AUTH_TLS al servidor pero no la sigue con el ClientHello debido a un problema con tlshd. Cuando se alcanza el tiempo de espera en el servidor, el servidor enviará un FIN, lo que activa una solicitud de cancelación a través de xs_reset_transport(). Cuando se alcanza el tiempo de espera en el cliente, ocurre otra solicitud de cancelación a través de xs_tls_handshake_sync().\n\nAñadir un test_and_set_bit(HANDSHAKE_F_REQ_COMPLETED) en la ruta de cancelación pendiente para que las cancelaciones duplicadas puedan ser detectadas."}],"metrics":{},"references":[{"url":"https://git.kernel.org/stable/c/011ae80c49d9bfa5b4336f8bd387cd25c7593663","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/15564bd67e2975002f2a8e9defee33e321d3183f","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/3c330f1dee3cd92b57e19b9d21dc8ce5970b09be","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/e1641177e7fb48a0a5a06658d4aab51da6656659","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"}]}}]}