CVE-2026-72473: xprtrdma: Decouple req recycling from RPC completion
In the Linux kernel, the following vulnerability has been resolved:
xprtrdma: Decouple req recycling from RPC completion
rlkref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdmareq could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (scunmapcount > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rlkref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer.
Give rlkref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdmapreparesendsges() takes a Send-side reference unconditionally after WR preparation succeeds. xprtrdmafreeslot() and xprtrdmabcfreerqst() drop the RPC-layer reference; rpcrdmasendctxunmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off.
The existing krefinit(&req->rlkref) call in rpcrdmapreparesendsges() is removed. Initialization moves to the slot-allocation paths (xprtrdmaallocslot and rpcrdmabcrqstget), and the release callback re-arms rlkref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry.
Three invariants follow:
- Any rpcrdmareq held by an rpcrqst has rlkref >= 1. xprtrdmaallocslot(), rpcrdmabcrqstget(), and the backlog-wake branch in xprtrdmaallocslot() each krefinit rlkref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gssrefresh failure or signal during callconnect, for example) would drive xprtrelease() -> xprtrdmafreeslot() -> krefput against a refcount of zero, saturating refcountt and stranding the slot.
- The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdmapreparesendsges() runs rpcrdmasendctxcancel(), which DMA-unmaps the sendctx and clears screq without touching rlkref. The sendctx ring walks in rpcrdmasendctxputlocked() and rpcrdmasendctxsdestroy() skip entries with screq == NULL, so a burst of -EIO marshal failures cannot hold reqs off rbsendbufs.
- The release callback re-arms rlkref so the next consumer enters with the invariant satisfied.
Replies now complete the RPC directly. rpcrdmareplyhandler() calls rpcrdmacompleterqst() in place of krefput on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwrunmapasync() and is unaffected.
Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdmasendctxsdestroy() walks the active range and runs rpcrdmasendctxunmap() on each entry with a non-NULL screq before the request buffers are reset, and is moved ahead of rpcrdmareqsreset() in rpcrdmaxprtdisconnect() so the reqs are still in their pre-reset state when the Send-side refs are released.
The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bcprealloc req from rpcrdmareqrelease() re-adds it to bcpalist. The disconnect in xprtrdmadestroy() runs after xprtdestroybackchannel() has already emptied bcpalist, so the drained reqs would otherwise leak. xprtrdmadestroy() now runs xprtrdmabcdestroy(xprt, 0) a second time after the disconnect to reclaim them.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 6.8.0-147.147 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 6.8.0-1067.70 - Upgrade
Upgrade
ubuntu/linux-aws-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1013.13~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79 - Upgrade
Upgrade
ubuntu/linux-azure-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 6.8.0-1069.76 - Upgrade
Upgrade
ubuntu/linux-azure-fde-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1016.16~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79 - Upgrade
Upgrade
ubuntu/linux-gcp-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1013.13~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 6.8.0-1066.74 - Upgrade
Upgrade
ubuntu/linux-gkeopto a version that resolves this vulnerability.Fixed in 6.8.0-1052.56 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-34.34~24.04.1 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 6.8.0-1067.68 - Upgrade
Upgrade
ubuntu/linux-lowlatencyto a version that resolves this vulnerability.Fixed in 6.8.0-147.147.1 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegrato a version that resolves this vulnerability.Fixed in 6.8.0-1035.38 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 6.8.0-1064.67 - Upgrade
Upgrade
ubuntu/linux-oracle-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1012.12~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-34.34.1~24.04.1 - Upgrade
Upgrade
ubuntu/linux-bluefieldto a version that resolves this vulnerability.Fixed in 6.8.0-1033.38 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 6.8.1-1062.63 - Upgrade
Upgrade
ubuntu/linux-aws-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1067.70+fips1 - Upgrade
Upgrade
ubuntu/linux-azure-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79+fips1 - Upgrade
Upgrade
ubuntu/linux-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-147.147+fips1 - Upgrade
Upgrade
ubuntu/linux-gcp-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79+fips1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-34.34 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.0.0-1016.16 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 7.0.0-1007.8 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1012.12 - Upgrade
Upgrade
ubuntu/linux-raspito a version that resolves this vulnerability.Fixed in 7.0.0-1020.20 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.0.0-34.34.1 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-34.34.1
Event History
Frequently Asked Questions
What is the severity of CVE-2026-72473?
The severity of CVE-2026-72473 is rated at 28, indicating a potentially high impact.
What systems are affected by CVE-2026-72473?
CVE-2026-72473 affects the Linux kernel, particularly implementations that utilize the xprtrdma transport.
How do I fix CVE-2026-72473?
To fix CVE-2026-72473, you should update your Linux kernel to the version that includes the patch addressing this vulnerability.
What are the risks associated with CVE-2026-72473?
The risks associated with CVE-2026-72473 include potential denial of service or exploitation by attackers leveraging RPC requests.
Is CVE-2026-72473 a remote code execution vulnerability?
CVE-2026-72473 is not classified as a remote code execution vulnerability, but it could lead to denial of service conditions.