{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-93228", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-93228" ], "published": "2026-09-24T15:29:45Z", "summary": "svcrdma: Reject Write/Reply chunks with segcount 0", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsvcrdma: Reject Write/Reply chunks with segcount 0\n\nA peer can send a Write or Reply chunk whose segcount field is zero.\nxdr_check_write_chunk() only rejects segcount > rc_maxpages, so zero\npasses the range check, and xdr_inline_decode(stream, 0) returns the\ncurrent (non-NULL) cursor without advancing. The function returns\ntrue and pcl_alloc_write() then links a struct svc_rdma_chunk with\nch_segcount == 0 onto rc_write_pcl or rc_reply_pcl.\n\nAn earlier patch in this series made pcl_for_each_segment() safe for\nch_segcount == 0, so this no longer drives the memory walk it used\nto. Rejecting the malformed frame at the decode boundary is still\nworthwhile as defense in depth: it keeps degenerate zero-segment\nchunks off the parsed chunk lists entirely, so any future consumer\nthat walks ch_segments directly cannot observe one, and it makes the\nzero-floor easy to backport to trees where the macro change is more\nintrusive. RFC 8166 has no meaning for a Write/Reply chunk that\ndescribes no remote buffer, so no legitimate client is affected.\n\nxdr_check_reply_chunk() funnels Reply chunks through\nxdr_check_write_chunk() and inherits the same rejection.\n\npcl_alloc_write() also links each chunk onto the parsed chunk list\nbefore filling its segment array. If a future change weakens the\nsegcount-0 rejection, an incomplete chunk is visible to consumers\nduring the fill loop. Reorder so that list_add_tail() follows the\nsegment fill loop, ensuring only fully-populated chunks appear on\nthe list.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": null, "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-93228" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/fe533ae1bed2ef2b3d54ee7ab410da1874ed3d4f" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/a798714b58041e88716db3bf8fb03ae13eecd54a" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/45dbdb2637b7fc5f1355b588780d2a7fb0516805" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/9808eb7656666acc7291bae9ab6b987bd16e47e0" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-09-25T05:22:58Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 9.1, "cvss_v3_severity": "Critical", "scenario": "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() \u2192 svc_rdma_xdr_decode_req() \u2192 xdr_check_write_list()/xdr_check_reply_chunk() \u2192 xdr_check_write_chunk() accepted that field over iWARP or routable RoCEv2.\nAC: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.\nPR: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.\nUI: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.\nS: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.\nC: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.\nI: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.\nA: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." } } }