UBUNTU-CVE-2026-72473: Medium severity ubuntu/linux-hwe-edge vulnerability
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
Which systems are exposed to this issue?
The affected Ubuntu kernel package families listed are linux, linux-azure, linux-gcp, linux-aws-fips, linux-azure-fips, linux-fips, linux-gcp-fips, and linux-realtime. The vulnerable code is in the kernel xprtrdma component.
What conditions are required for the use-after-free to occur?
The problematic path involves an RDMA send using only pre-registered buffers, so no DMA unmap is required (sc_unmap_count is zero). A reply can then release the request while the HCA may still be DMA-reading its send buffer.
What is the practical impact of the flaw?
A request can be returned to the free pool before the send-side DMA activity has completed, creating a use-after-free condition. The provided severity data rates the issue medium with a 5.9 score and indicates local access and low privileges are required.
What does the fix change?
The fix separates the request's RPC-layer and send-side lifetimes. A send-side reference is now taken unconditionally after work-request preparation, and the request is returned to the free pool only after both the RPC and send-side references have been released.