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

xprtrdma: Fix bcall rep leak and unbounded peek

rpcrdma_is_bcall() decodes a reply's first words to decide whether
the frame is a backchannel call. Two issues in that decode path
let a short or malformed reply leak the receive buffer and drain
the Receive queue.

First, the speculative peek

p = xdr_inline_decode(xdr, 0);
/* five p++ reads follow */

asks xdr_inline_decode() for zero bytes, which returns xdr->p
without consulting xdr->end. The five subsequent __be32 reads can
then walk up to 20 bytes past the wire payload into stale regbuf
contents and misclassify the reply as a backchannel call.

Second, after the post-peek

p = xdr_inline_decode(xdr, 3 * sizeof(*p));
if (unlikely(!p))
return true;

the short-header arm returns true without calling
rpcrdma_bc_receive_call(). The contract with the caller is that a
true return transfers ownership of rep to the backchannel path:

rpcrdma_reply_handler()
if (rpcrdma_is_bcall(r_xprt, rep))
return; /* bare return, skips out_post */
...
out_post:
rpcrdma_post_recvs(r_xprt, credits + ...);

Because rpcrdma_bc_receive_call() never ran, no one took rep, but
rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put()
and rpcrdma_post_recvs(). The rep, with its persistently
DMA-mapped receive buffer, is orphaned on rb_all_reps and freed
only at transport teardown. This completion reposts nothing, so
its slot is reclaimed only when a later forward-channel reply
reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to
backfill; absent that traffic the Receive queue drains and the
peer's Sends draw RNR NAKs.

Fix by consulting xdr->end after the zero-length peek so the five
__be32 reads cannot run unless 20 bytes of wire payload remain. A
byte-precise comparison against xdr->end is required because a
non-4-aligned receive rounds the stream's word count up past the
true payload. Also return false from the short-header arm so the
reply falls through the normal out_norqst cleanup chain
(rpcrdma_rep_put() plus rpcrdma_post_recvs()).
Published: 2026-08-15
Score: 9.8 Critical
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Linux kernel's rpcrdma module misprocesses short or malformed RPC replies. A zero-length peek coupled with unchecked bounds allows the kernel to read up to 20 bytes past the end of the receive buffer, potentially exposing stale data. This scenario is a classic buffer underrun (CWE-125). The misclassification of such replies as backchannel requests causes the reply buffer to be orphaned and never freed, draining the receive queue. This can result in Receive‑Not‑Ready (RNR) NAKs and a denial of service for RDMA traffic. Based on the description, it is inferred that the vulnerability can be triggered remotely by an attacker with the ability to send crafted RDMA replies.

Affected Systems

All Linux kernel releases that include the rpcrdma module prior to the patch commit are potentially vulnerable. No specific vendor version range is specified; the vulnerability is tied to the rpcrdma backchannel reply handling code in the kernel source. Administrators should evaluate whether their current kernel contains the unpatched rpcrdma implementation and apply the updated kernel when available.

Risk and Exploitability

The CVSS score of 9.8 places this issue in the critical severity range. The EPSS score of less than 1% suggests that widespread exploitation is unlikely at present, but the impact is severe. The vulnerability is not listed in the CISA KEV catalog; however, the combination of a critical CVSS score and the ability to disrupt RDMA services warrants immediate attention and remediation. Based on the description, it is inferred that the likely attack vector is remote RDMA traffic.

Generated by OpenCVE AI on August 22, 2026 at 06:55 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply an updated Linux kernel that contains the rpcrdma backchannel reply patch.
  • Coordinate with your distribution vendor to confirm that the latest kernel update includes the rpcrdma fix before applying it.
  • Reboot the system after updating the kernel so the patched version is loaded and active.

Generated by OpenCVE AI on August 22, 2026 at 06:55 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 22 Aug 2026 04:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-119
CWE-400

Thu, 20 Aug 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-125
References
Metrics threat_severity

None

 threat_severity

Moderate

Mon, 17 Aug 2026 18:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-119
CWE-400

Mon, 17 Aug 2026 16:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-125

Mon, 17 Aug 2026 06:00:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 9.8, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'}

Sat, 15 Aug 2026 12:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-125

Sat, 15 Aug 2026 06:00:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix bcall rep leak and unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs. Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).
Title xprtrdma: Fix bcall rep leak and unbounded peek
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-17T05:44:32.887Z

Reserved: 2026-08-09T03:40:39.933Z

Link: CVE-2026-72466

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-15T06:22:20.637

Modified: 2026-08-17T06:19:14.433

Link: CVE-2026-72466

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-08-15T00:00:00Z

Links: CVE-2026-72466 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-22T07:00:07Z

Weaknesses