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: n/a
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

In the Linux kernel, the rpcrdma module misprocesses short or malformed replies from a remote client. A zero‑length peek allows the kernel to read beyond the end of the receive buffer, which can read up to 20 bytes of stale data and misclassify the reply as a backchannel request. This misclassification causes the reply buffer to be orphaned and never freed. As a result, the kernel’s receive queue can drain, leading to Receive‑Not‑Ready (RNR) NAKs that impair network performance. The vulnerability can be exploited remotely by an attacker who can send crafted RPC replies, potentially causing a denial of service. Affected Systems The bug affects the Linux kernel itself; no specific version range is provided in the CVE data, so all kernel builds that include the rpcrdma module before the commit that fixes the issue are potentially vulnerable. Risk and Exploitability The CVE lacks an assigned CVSS score or EPSS probability, but the conditions required for exploitation—delivery of a malformed RPC reply over RDMA—are achievable by anyone with network access to the kernel’s RDMA interface. No CISA KEV flag has been set, yet the impact level is high because an unpatched system can be taken down by a remote attacker. The exploit path is therefore a remote attack via the RDMA channel.

Affected Systems

Linux kernel releases that include the rpcrdma module before the patch commit

Risk and Exploitability

Because no CVSS or EPSS values are available, the severity must be judged from the described impact. The vulnerability permits a remote attacker, typically over a network using RDMA, to trigger out‑of‑bounds reads and drain the receive queue, leading to a denial of service. The lack of an EPSS score suggests no known widespread exploitation, but the potential for remote disruption is significant, especially in environments that rely on RDMA for performance.

Generated by OpenCVE AI on August 15, 2026 at 11:31 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply an updated Linux kernel that incorporates the patch fixing the rpcrdma backchannel reply handling.
  • Coordinate with the distribution vendor to verify that the latest security updates for the kernel include the rpcrdma fix before applying the update.
  • Reboot the system after updating the kernel so the patched version is loaded and active.
  • Optional: enable logging or monitoring for RDMA traffic and RNR NAK occurrences to detect any lingering effects of the vulnerability.

Generated by OpenCVE AI on August 15, 2026 at 11:31 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

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-15T05:57:09.847Z

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-15T06:22:20.637

Link: CVE-2026-72466

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-15T11:45:03Z

Weaknesses