svcrdma: Fix pcl_for_each_segment for empty chunks

Overview

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

svcrdma: Fix pcl_for_each_segment for empty chunks

When a parsed chunk list contains a chunk whose ch_segcount is zero, pcl_for_each_segment computes its inclusive upper bound as &chunk->ch_segments[ch_segcount - 1]. ch_segcount is u32, so the subtraction wraps to 0xFFFFFFFF and the bound lands far past the ch_segments flex array. The loop body then walks unrelated memory at sizeof(struct svc_rdma_segment) stride until it faults.

A zero-segcount chunk is reachable from the wire: xdr_check_write_chunk() only rejects segcount values greater than rc_maxpages, and pcl_alloc_write() links a freshly allocated chunk onto rc_write_pcl/rc_reply_pcl before its segment-fill loop runs, so a Write or Reply chunk advertising zero segments leaves ch_segcount == 0 on the list. When the transport has negotiated Send-With-Invalidate, svc_rdma_get_inv_rkey() iterates all four PCLs with pcl_for_each_segment and dereferences segment->rs_handle on each iteration, turning the underflow into an out-of-bounds read and a general protection fault.

xdr_check_write_list / xdr_check_reply_chunk
  pcl_alloc_write()
    chunk = pcl_alloc_chunk(...)  /* ch_segcount = 0 */
    list_add_tail(&chunk->ch_list, &pcl->cl_chunks)
    /* fill loop iterates zero times for wire segcount 0 */

svc_rdma_get_inv_rkey()
  pcl_for_each_chunk(rc_write_pcl)
    pcl_for_each_segment(segment, chunk)
      pos <= &ch_segments[0u - 1u]  /* 0xFFFFFFFF */
      segment->rs_handle            /* OOB read -> GPF */

Fix by switching the macro to a half-open upper bound that uses ch_segcount directly. For ch_segcount == 0 the loop start equals the loop end and the body is skipped; for ch_segcount > 0 the iteration range is unchanged. All six existing call sites in net/sunrpc/xprtrdma/svc_rdma_recvfrom.c and net/sunrpc/xprtrdma/svc_rdma_rw.c remain correct under the new bound, so no caller changes are needed.

Affected

• Linux >= 78147ca8b4a9b6cf0e597ddd6bf17959e08376c2 < 1e2e3481e39103a386b86be1c33eaef97cbdf16e
• Linux >= 78147ca8b4a9b6cf0e597ddd6bf17959e08376c2 < 3a78b841879c2a3243f74edc514236fb2907167f
• Linux >= 78147ca8b4a9b6cf0e597ddd6bf17959e08376c2 < 06d0390c37fa6714624af771bd72bbf1a7ed9bb1
• Linux >= 78147ca8b4a9b6cf0e597ddd6bf17959e08376c2 < 9c5a03c3dc505c0295339b0a1b9e4fe36447e482
• Linux >= 78147ca8b4a9b6cf0e597ddd6bf17959e08376c2 < a1c954ca4977a4e6ec73ef92fe48073ec54f9fc8
• Linux >= 78147ca8b4a9b6cf0e597ddd6bf17959e08376c2 < 6d33a7e6bf6c6b293a266a617201285a1ad32c56
• Linux >= 78147ca8b4a9b6cf0e597ddd6bf17959e08376c2 < b7713a784c59515d0aba558c8f5df6a0164dd3a9
• Linux 5.11

Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.

Vendor advisories

• Red Hat VEX · Moderate · affected: Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 8, Red Hat Enterprise Linux 9, Red Hat OpenShift Container Platform 4 · no fix planned: Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 8, Red Hat Enterprise Linux 9, Red Hat OpenShift Container Platform 4 · updated 2026-09-16 · vex