sunrpc: wait for in-flight TLS handshake callback when cancel loses race
In the Linux kernel, the following vulnerability has been resolved: sunrpc: wait for in-flight TLS handshake callback when cancel loses race When wait_for_completion_interruptible_timeout() in svc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tls_handshake_cancel() then returns false, handshake_complete() has won the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and is about to invoke svc_tcp_handshake_done(), but the callback's side effects on xpt_flags and on svsk->sk_handshake_done have not yet committed. The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result. If the callback has executed set_bit(XPT_TLS_SESSION) but not yet clear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session, enqueues the transport, and returns. svc_xprt_received() then clears XPT_BUSY, a worker thread picks the transport up, the dispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set, and xpo_handshake is invoked a second time. That svc_tcp_handshake() calls init_completion(&svsk->sk_handshake_done) while the original callback concurrently calls complete_all() on it, corrupting the embedded swait_queue. If the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet entered svc_tcp_handshake_done(), svc_tcp_handshake() reads XPT_TLS_SESSION as clear and tears the connection down even though the handshake is about to succeed. Wait for the callback to commit before inspecting xpt_flags. The completion is guaranteed
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.12.97, 6.18.40, 6.6.145, 7.1.5
- CVEs
- CVE-2026-72221
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 23:55 UTC · Revision 1
Source evidence
sunrpc: wait for in-flight TLS handshake callback when cancel loses race
core-osv · Original sourcePublished 15 Aug 2026, 05:54 UTC
In the Linux kernel, the following vulnerability has been resolved: sunrpc: wait for in-flight TLS handshake callback when cancel loses race When wait_for_completion_interruptible_timeout() in svc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tls_handshake_cancel() then returns false, handshake_complete() has won the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and is about to invoke svc_tcp_handshake_done(), but the callback's side effects on xpt_flags and on svsk->sk_handshake_done have not yet committed. The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result. If the callback has executed set_bit(XPT_TLS_SESSION) but not yet clear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session, enqueues the transport, and returns. svc_xprt_received() then clears XPT_BUSY, a worker thread picks the transport up, the dispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set, and xpo_handshake is invoked a second time. That svc_tcp_handshake() calls init_completion(&svsk->sk_handshake_done) while the original callback concurrently calls complete_all() on it, corrupting the embedded swait_queue. If the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet entered svc_tcp_handshake_done(), svc_tcp_handshake() reads XPT_TLS_SESSION as clear and tears the connection down even though the handshake is about to succeed. Wait for the callback to commit before inspecting xpt_flags. The completion is guaranteed
osv:CVE-2026-72221
Kernel
Fixed versions: 6.6.145, 6.12.97, 6.18.40, 7.1.5
Complete source record
{
"id": "40c70cf3a33fc508439e41e2c18f10a38a4110fa15798cd6c98060e659b2e642",
"url": "https://osv.dev/vulnerability/CVE-2026-72221",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "sunrpc: wait for in-flight TLS handshake callback when cancel loses race",
"summary": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: wait for in-flight TLS handshake callback when cancel loses race When wait_for_completion_interruptible_timeout() in svc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tls_handshake_cancel() then returns false, handshake_complete() has won the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and is about to invoke svc_tcp_handshake_done(), but the callback's side effects on xpt_flags and on svsk->sk_handshake_done have not yet committed. The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result. If the callback has executed set_bit(XPT_TLS_SESSION) but not yet clear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session, enqueues the transport, and returns. svc_xprt_received() then clears XPT_BUSY, a worker thread picks the transport up, the dispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set, and xpo_handshake is invoked a second time. That svc_tcp_handshake() calls init_completion(&svsk->sk_handshake_done) while the original callback concurrently calls complete_all() on it, corrupting the embedded swait_queue. If the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet entered svc_tcp_handshake_done(), svc_tcp_handshake() reads XPT_TLS_SESSION as clear and tears the connection down even though the handshake is about to succeed. Wait for the callback to commit before inspecting xpt_flags. The completion is guaranteed",
"evidence": "osv:CVE-2026-72221",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.6.145",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.97",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.40",
"evidence": "/affected/1/ranges"
},
{
"value": "7.1.5",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "critical",
"structured": {
"id": "CVE-2026-72221",
"aliases": [
"CVE-2026-72221"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "b3cbf98e2fdf3cb147a95161560cd25987284330"
},
{
"fixed": "0d8ceb39884148dc7a2fdf71e1cac5961ed1d2b9"
},
{
"fixed": "e0f4691d42a54d359d8b64509fd9ab938d4f2a33"
},
{
"fixed": "65b23bec1fca6e9ebdc3e6041ebf8c6ab074141b"
},
{
"fixed": "a4f878e8ecd729ccf2e50993444e217583adeace"
},
{
"fixed": "d00e32f84ca1a77cb67a3fbf59f58dada95f5a21"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-72221.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.4.0"
},
{
"fixed": "6.6.145"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.97"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.40"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "7.1.5"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-72221.json"
}
}
],
"modified": "2026-10-28T02:30:40.371335659Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/0d8ceb39884148dc7a2fdf71e1cac5961ed1d2b9",
"https://git.kernel.org/stable/c/65b23bec1fca6e9ebdc3e6041ebf8c6ab074141b",
"https://git.kernel.org/stable/c/a4f878e8ecd729ccf2e50993444e217583adeace",
"https://git.kernel.org/stable/c/d00e32f84ca1a77cb67a3fbf59f58dada95f5a21",
"https://git.kernel.org/stable/c/e0f4691d42a54d359d8b64509fd9ab938d4f2a33",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/72xxx/CVE-2026-72221.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-72221",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/72xxx/CVE-2026-72221.json"
}
},
"related_cves": [
{
"value": "CVE-2026-72221",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 508177,
"published_at": "2026-08-15T05:54:14.539+00:00"
}