CVE-2026-72222
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedIn the Linux kernel, the following vulnerability has been resolved: sunrpc: pin svc_xprt across the asynchronous TLS handshake callback svc_tcp_handshake() stores the raw svc_xprt pointer in tls_handshake_args.ta_data and submits the request through tls_server_hello_x509(). The handshake core takes only sock_hold(req->hr_sk); nothing references the embedding struct svc_sock that svc_tcp_handshake_done() reaches via container_of(). Two close races leave the in-flight callback writing through a freed svc_sock. svc_sock_free() calls tls_handshake_cancel() and discards its return value: a false return means handshake_complete() has already set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have finished, yet svc_sock_free() proceeds to kfree(svsk). The cancel-loser fall-through inside svc_tcp_handshake() itself produces the same window: when wait_for_completion_interruptible_timeout() returns <= 0 (timeout or signal) and tls_handshake_cancel() returns false, the function does not drain, returns, and svc_handle_xprt() calls svc_xprt_received(), which clears XPT_BUSY and can drop the last reference. A concurrent close then runs svc_sock_free() while svc_tcp_handshake_done() is still updating xpt_flags and walking svsk->sk_handshake_done. The corruption surfaces as set_bit/clear_bit RMW into the freed xpt_flags slab slot and as complete_all() walking and writing the freed wait_queue_head_t list embedded in sk_handshake_done -- a slab-corruption primitive, not a benign read. The path is reachable on any TLS-enabled NFS server whenever a connection close overlaps the tlshd downcall delivery window; the interruptible wait means signal delivery suffices, not just SVC_HANDSHAKE_TO expiry. Take svc_xprt_get(xprt) immediately before tls_server_hello_x509() so the in-flight callback owns its own reference. Release it on the two edges where the callback is guaranteed not to fire -- submission failure from tls_server_hello_x509() and a successful tls_handshake_cancel() -- and at the tail of svc_tcp_handshake_done() after complete_all(). [cel: rewrote commit message to describe the actual change]
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysisA detailed technical summary for this CVE is being prepared.
CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scoped- 1. Apply the kernel patch that adds svc_xprt_get(xprt) immediately before tls_server_hello_x509() in svc_tcp_handshake().
- 2. The patch must add reference counting to prevent the svc_sock from being freed while the TLS handshake callback is in-flight.
- 3. Ensure the reference is released on three edges: (a) submission failure from tls_server_hello_x509(), (b) successful tls_handshake_cancel(), and (c) at the tail of svc_tcp_handshake_done() after complete_all().
- 4. Rebuild and deploy the patched kernel.
- 5. Restart any TLS-enabled NFS services to ensure the new code path is exercised.
Generated from the published advisory — verify against the referenced sources before acting.
There is no version to upgrade to and no patch to apply. Every affected install stays exposed until the vendor ships a fix — or somebody else builds one.
Free. We build fixes in the order the community asks for them — and we’ll tell you the moment this one lands.
We develop and verify an original fix where the vendor hasn’t, from $5,750. Deployed to your staging first — never straight to production.
Scope it with usSee what else the community needs solved on the solutions-needed board.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-72222 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-72222 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data