Bug 2516663 (CVE-2026-72465)

Summary: CVE-2026-72465 kernel: xprtrdma: Sanitize the reply credit grant after parsing
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel's `xprtrdma` component. A remote attacker can exploit this by sending specially crafted RPC over RDMA replies containing an inflated credit grant. This vulnerability can lead to excessive allocation of Receive Work Requests, potentially causing a Denial of Service (DoS) due to resource exhaustion and system instability.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-08-15 06:24:39 UTC 
In the Linux kernel, the following vulnerability has been resolved:

xprtrdma: Sanitize the reply credit grant after parsing

The out_norqst exit in rpcrdma_reply_handler() branches away before
the credit clamp, so a reply that matches no pending request reaches
out_post carrying the raw credit value parsed from the wire.
rpcrdma_post_recvs() does not bound its @needed argument: the refill
loop allocates and chains Receive WRs until the count is satisfied or
allocation fails. A peer that sends a well-formed reply carrying an
unknown XID and an inflated credit grant therefore drives rep
allocation and Receive posting past re_max_requests on every such
reply.

Move the clamp to immediately after the credit field is parsed,
ahead of the first branch that can reach out_post, so every later
consumer sees a sanitized value. The cwnd update stays on the
matched-request path.
Comment 1 Keith Grant 2026-08-19 17:36:10 UTC 
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026081534-CVE-2026-72465-1064@gregkh/T