In the Linux kernel, the following vulnerability has been resolved:
svcrdma: Reject Write/Reply chunks with segcount 0
A peer can send a Write or Reply chunk whose segcount field is zero.
xdr_check_write_chunk() only rejects segcount > rc_maxpages, so zero
passes the range check, and xdr_inline_decode(stream, 0) returns the
current (non-NULL) cursor without advancing. The function returns
true and pcl_alloc_write() then links a struct svc_rdma_chunk with
ch_segcount == 0 onto rc_write_pcl or rc_reply_pcl.
An earlier patch in this series made pcl_for_each_segment() safe for
ch_segcount == 0, so this no longer drives the memory walk it used
to. Rejecting the malformed frame at the decode boundary is still
worthwhile as defense in depth: it keeps degenerate zero-segment
chunks off the parsed chunk lists entirely, so any future consumer
that walks ch_segments directly cannot observe one, and it makes the
zero-floor easy to backport to trees where the macro change is more
intrusive. RFC 8166 has no meaning for a Write/Reply chunk that
describes no remote buffer, so no legitimate client is affected.
xdr_check_reply_chunk() funnels Reply chunks through
xdr_check_write_chunk() and inherits the same rejection.
pcl_alloc_write() also links each chunk onto the parsed chunk list
before filling its segment array. If a future change weakens the
segcount-0 rejection, an incomplete chunk is visible to consumers
during the fill loop. Reorder so that list_add_tail() follows the
segment fill loop, ensuring only fully-populated chunks appear on
the list.
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
CVSS Score: 9.1
AV:N - A remote NFS/RDMA peer places a Write or Reply chunk with segcount 0 in the RPC-over-RDMA transport header; svc_rdma_recvfrom() → svc_rdma_xdr_decode_req() → xdr_check_write_list()/xdr_check_reply_chunk() → xdr_check_write_chunk() accepted that field over iWARP or routable RoCEv2.
AC:L - The attacker sets RPCRDMA_CMP_F_SND_W_INV_OK in the RDMA-CM private connect blob (svc_rdma_parse_connect_private) and sends a Write/Reply chunk with segcount 0; xdr_check_write_chunk() only rejected segcount > rc_maxpages, xdr_inline_decode(0) returns the cursor, and pcl_alloc_write() links a ch_segcount==0 chunk with no race.
PR:N - xdr_check_write_chunk() and pcl_alloc_write() run in svc_rdma_xdr_decode_req() from svc_rdma_recvfrom() while parsing the transport header, before svc_xprt_do_recv() calls svc_process()/svc_authenticate(); RDMA CM accept performs no NFS credential check.
UI:N - The attacker only needs to connect to a listening NFS/RDMA service and send an RPC-over-RDMA Call whose Write list or Reply chunk has segcount 0; no victim mount, click, or other user action is required.
S:U - pcl_alloc_write() installs the empty chunk on the host kernel rc_write_pcl/rc_reply_pcl, and the subsequent heap walk and general protection fault stay inside nfsd's RPC-over-RDMA server; this is not a VM, IOMMU, or sandbox escape.
C:H - Accepting segcount 0 in xdr_check_write_chunk() lets pcl_alloc_write() put a ch_segcount==0 Write/Reply chunk on the parsed list; pcl_for_each_segment then uses &ch_segments[0u-1u] and walks adjacent kernel heap at sizeof(struct svc_rdma_segment) stride, an unbounded out-of-bounds read.
I:N - svc_rdma_get_inv_rkey() only loads segment->rs_handle from the overrun pointer to choose an invalidate rkey; Write/Reply encode and RDMA Write paths index with segno < ch_segcount and skip or return -E2BIG on an empty chunk, so there is no out-of-bounds write or control-flow hijack.
A:H - The underflowed pcl_for_each_segment walk of the empty Write/Reply chunk continues until it hits unmapped memory and raises a general protection fault, oopsing or panicking the kernel, and the peer can send another zero-segcount Call to repeat it.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
None |
| User Interaction |
None |
Availability Impact |
High |
AV:N - A remote NFS/RDMA peer places a Write or Reply chunk with segcount 0 in the RPC-over-RDMA transport header; svc_rdma_recvfrom() → svc_rdma_xdr_decode_req() → xdr_check_write_list()/xdr_check_reply_chunk() → xdr_check_write_chunk() accepted that field over iWARP or routable RoCEv2.
AC:L - The attacker sets RPCRDMA_CMP_F_SND_W_INV_OK in the RDMA-CM private connect blob (svc_rdma_parse_connect_private) and sends a Write/Reply chunk with segcount 0; xdr_check_write_chunk() only rejected segcount > rc_maxpages, xdr_inline_decode(0) returns the cursor, and pcl_alloc_write() links a ch_segcount==0 chunk with no race.
PR:N - xdr_check_write_chunk() and pcl_alloc_write() run in svc_rdma_xdr_decode_req() from svc_rdma_recvfrom() while parsing the transport header, before svc_xprt_do_recv() calls svc_process()/svc_authenticate(); RDMA CM accept performs no NFS credential check.
UI:N - The attacker only needs to connect to a listening NFS/RDMA service and send an RPC-over-RDMA Call whose Write list or Reply chunk has segcount 0; no victim mount, click, or other user action is required.
S:U - pcl_alloc_write() installs the empty chunk on the host kernel rc_write_pcl/rc_reply_pcl, and the subsequent heap walk and general protection fault stay inside nfsd's RPC-over-RDMA server; this is not a VM, IOMMU, or sandbox escape.
C:H - Accepting segcount 0 in xdr_check_write_chunk() lets pcl_alloc_write() put a ch_segcount==0 Write/Reply chunk on the parsed list; pcl_for_each_segment then uses &ch_segments[0u-1u] and walks adjacent kernel heap at sizeof(struct svc_rdma_segment) stride, an unbounded out-of-bounds read.
I:N - svc_rdma_get_inv_rkey() only loads segment->rs_handle from the overrun pointer to choose an invalidate rkey; Write/Reply encode and RDMA Write paths index with segno < ch_segcount and skip or return -E2BIG on an empty chunk, so there is no out-of-bounds write or control-flow hijack.
A:H - The underflowed pcl_for_each_segment walk of the empty Write/Reply chunk continues until it hits unmapped memory and raises a general protection fault, oopsing or panicking the kernel, and the peer can send another zero-segcount Call to repeat it.
CVSS 3.1