Skip to main content

Linux Kernel CVE-2026-72473

| EUVDEUVD-2026-59372 CRITICAL
2026-08-15 Linux GHSA-7rpw-2p75-rwvf
Critical
Disputed · 9.8 Vendor: Linux
Share

Severity by source

Sources disagree (Medium–Critical)
Vendor (Linux) PRIMARY
9.8 CRITICAL
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
7.0 HIGH

Triggering needs an active local RDMA workload and winning a free-vs-DMA race (AV:L, AC:H, PR:L); a kernel UAF can corrupt memory with high CIA impact, though availability (crash) is the most likely outcome.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
4.0 AV:L/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
SUSE
5.8 HIGH
AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H
Red Hat
7.0 MEDIUM
qualitative

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: Linux

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Aug 17, 2026 - 09:42 vuln.today
CVSS changed
Aug 17, 2026 - 06:22 NVD
9.8 (CRITICAL)
Patch available
Aug 15, 2026 - 07:20 EUVD
CVE Published
Aug 15, 2026 - 05:57 cve.org
CRITICAL 9.8
CVE Published
Aug 15, 2026 - 05:57 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

xprtrdma: Decouple req recycling from RPC completion

rl_kref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdma_req could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (sc_unmap_count > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer.

Give rl_kref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdma_prepare_send_sges() takes a Send-side reference unconditionally after WR preparation succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop the RPC-layer reference; rpcrdma_sendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off.

The existing kref_init(&req->rl_kref) call in rpcrdma_prepare_send_sges() is removed. Initialization moves to the slot-allocation paths (xprt_rdma_alloc_slot and rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref 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 rpcrdma_req held by an rpc_rqst has rl_kref >= 1.

xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot.

  • The Send-side reference is taken only after WR prep

succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs.

  • The release callback re-arms rl_kref so the next consumer

enters with the invariant satisfied.

Replies now complete the RPC directly. rpcrdma_reply_handler() calls rpcrdma_complete_rqst() in place of kref_put on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwr_unmap_async() 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. rpcrdma_sendctxs_destroy() walks the active range and runs rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req before the request buffers are reset, and is moved ahead of rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() 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 bc_prealloc req from rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has already emptied bc_pa_list, so the drained reqs would otherwise leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0) a second time after the disconnect to reclaim them.

AnalysisAI

Memory corruption in the Linux kernel's xprtrdma (RPC-over-RDMA / NFS-over-RDMA) transport arises from a use-after-free in request-slot lifetime management: the RPC Reply handler could drop the rl_kref refcount to zero and return an rpcrdma_req to its free pool while the RDMA HCA was still DMA-reading from that request's send buffer, specifically when a Send carried only pre-registered buffers (sc_unmap_count == 0). This affects Linux systems using RPC-over-RDMA transport (introduced around 5.3) and is fixed by decoupling req recycling from RPC completion. EPSS is low (0.21%, 12th percentile) and there is no public exploit identified at time of analysis; the auto-assigned 9.8 CVSS overstates real-world risk for a race-condition kernel bug on a niche transport.

Technical ContextAI

The affected code is xprtrdma, the kernel implementation of RPC-over-RDMA used chiefly by NFS/RDMA over InfiniBand or RoCE (RDMA over Converged Ethernet). The bug is a lifetime/reference-counting defect (CWE-416 Use-After-Free; CWE listed as N/A in the feed) in rpcrdma_req management: a single refcount, rl_kref, conflated two distinct lifetimes - gating when a Reply may wake its RPC task, and gating when the rpcrdma_req may return to its free pool. Because the marshal path only took the Send-side reference when SGEs required DMA-unmap, a Send composed solely of pre-registered buffers had no Send-side reference, so the Reply handler could free and recycle the req while the HCA continued DMA-reading its send buffer. The fix gives rl_kref a narrower job: the RPC layer takes one reference at slot allocation and rpcrdma_prepare_send_sges() unconditionally takes a Send-side reference after WR prep succeeds, so the req returns to the pool only after both owners release it; teardown ordering in rpcrdma_xprt_disconnect() was also reworked to drain sendctx entries before reqs are reset.

RemediationAI

Vendor-released patch: update to a fixed stable kernel - 6.1.178, 6.6.145, 6.12.97, 6.18.40, 7.1.5, or 7.2-rc1 (or later on each branch), per the git.kernel.org/stable commits referenced in EUVD-2026-59372 and https://nvd.nist.gov/vuln/detail/CVE-2026-72473. Apply the fix from your distribution's kernel update channel rather than cherry-picking, since the change touches slot allocation, send-completion, and disconnect teardown paths together. If immediate patching is not possible, the practical compensating control is to avoid the vulnerable code path: do not use RPC-over-RDMA/NFS-over-RDMA transports - mount NFS over TCP instead of rdma, which removes exposure entirely at the cost of RDMA's throughput and latency benefits; on hosts that do not need RDMA at all, ensure the RPC-over-RDMA transport is not loaded/enabled. There is no configuration flag that fixes the race while keeping RDMA transport in use, so the only durable remediation is the kernel upgrade.

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

CVE-2026-72473 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy