{"api_version":"1","generated_at":"2026-09-25T09:21:55+00:00","cve":"CVE-2026-93228","urls":{"html":"https://cve.report/CVE-2026-93228","api":"https://cve.report/api/cve/CVE-2026-93228.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-93228","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-93228"},"summary":{"title":"svcrdma: Reject Write/Reply chunks with segcount 0","description":"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.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-09-24 16:17:18","updated_at":"2026-09-25 05:17:00"},"problem_types":[],"metrics":[{"version":"3.1","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","score":"9.1","severity":"CRITICAL","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H","baseScore":9.1,"baseSeverity":"CRITICAL","attackVector":"NETWORK","attackComplexity":"LOW","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"NONE","availabilityImpact":"HIGH"}},{"version":"3.1","source":"CNA","type":"DECLARED","score":"9.1","severity":"CRITICAL","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H","data":{"baseScore":9.1,"baseSeverity":"CRITICAL","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H","version":"3.1"}}],"references":[{"url":"https://git.kernel.org/stable/c/a798714b58041e88716db3bf8fb03ae13eecd54a","name":"https://git.kernel.org/stable/c/a798714b58041e88716db3bf8fb03ae13eecd54a","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/45dbdb2637b7fc5f1355b588780d2a7fb0516805","name":"https://git.kernel.org/stable/c/45dbdb2637b7fc5f1355b588780d2a7fb0516805","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/fe533ae1bed2ef2b3d54ee7ab410da1874ed3d4f","name":"https://git.kernel.org/stable/c/fe533ae1bed2ef2b3d54ee7ab410da1874ed3d4f","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/9808eb7656666acc7291bae9ab6b987bd16e47e0","name":"https://git.kernel.org/stable/c/9808eb7656666acc7291bae9ab6b987bd16e47e0","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-93228","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-93228","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 78147ca8b4a9b6cf0e597ddd6bf17959e08376c2 fe533ae1bed2ef2b3d54ee7ab410da1874ed3d4f git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 78147ca8b4a9b6cf0e597ddd6bf17959e08376c2 a798714b58041e88716db3bf8fb03ae13eecd54a git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 78147ca8b4a9b6cf0e597ddd6bf17959e08376c2 45dbdb2637b7fc5f1355b588780d2a7fb0516805 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 78147ca8b4a9b6cf0e597ddd6bf17959e08376c2 9808eb7656666acc7291bae9ab6b987bd16e47e0 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 5.11","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 5.11 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.111 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.50 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.4 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3-rc1 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["net/sunrpc/xprtrdma/svc_rdma_pcl.c","net/sunrpc/xprtrdma/svc_rdma_recvfrom.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"fe533ae1bed2ef2b3d54ee7ab410da1874ed3d4f","status":"affected","version":"78147ca8b4a9b6cf0e597ddd6bf17959e08376c2","versionType":"git"},{"lessThan":"a798714b58041e88716db3bf8fb03ae13eecd54a","status":"affected","version":"78147ca8b4a9b6cf0e597ddd6bf17959e08376c2","versionType":"git"},{"lessThan":"45dbdb2637b7fc5f1355b588780d2a7fb0516805","status":"affected","version":"78147ca8b4a9b6cf0e597ddd6bf17959e08376c2","versionType":"git"},{"lessThan":"9808eb7656666acc7291bae9ab6b987bd16e47e0","status":"affected","version":"78147ca8b4a9b6cf0e597ddd6bf17959e08376c2","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["net/sunrpc/xprtrdma/svc_rdma_pcl.c","net/sunrpc/xprtrdma/svc_rdma_recvfrom.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"5.11"},{"lessThan":"5.11","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.12.*","status":"unaffected","version":"6.12.111","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.50","versionType":"semver"},{"lessThanOrEqual":"7.2.*","status":"unaffected","version":"7.2.4","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.3-rc1","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.12.111","versionStartIncluding":"5.11","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.50","versionStartIncluding":"5.11","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2.4","versionStartIncluding":"5.11","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3-rc1","versionStartIncluding":"5.11","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"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."}],"metrics":[{"cvssV3_1":{"baseScore":9.1,"baseSeverity":"CRITICAL","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H","version":"3.1"},"scenarios":[{"lang":"en","value":"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.\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."}]}],"providerMetadata":{"dateUpdated":"2026-09-25T05:09:48.089Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/fe533ae1bed2ef2b3d54ee7ab410da1874ed3d4f"},{"url":"https://git.kernel.org/stable/c/a798714b58041e88716db3bf8fb03ae13eecd54a"},{"url":"https://git.kernel.org/stable/c/45dbdb2637b7fc5f1355b588780d2a7fb0516805"},{"url":"https://git.kernel.org/stable/c/9808eb7656666acc7291bae9ab6b987bd16e47e0"}],"title":"svcrdma: Reject Write/Reply chunks with segcount 0","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-93228","datePublished":"2026-09-24T15:29:10.087Z","dateReserved":"2026-09-17T16:02:15.094Z","dateUpdated":"2026-09-25T05:09:48.089Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-09-24 16:17:18","lastModifiedDate":"2026-09-25 05:17:00","problem_types":[],"metrics":{"cvssMetricV31":[{"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H","baseScore":9.1,"baseSeverity":"CRITICAL","attackVector":"NETWORK","attackComplexity":"LOW","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"NONE","availabilityImpact":"HIGH"},"exploitabilityScore":3.9,"impactScore":5.2}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"93228","Ordinal":"1","Title":"svcrdma: Reject Write/Reply chunks with segcount 0","CVE":"CVE-2026-93228","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"93228","Ordinal":"1","NoteData":"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.","Type":"Description","Title":"svcrdma: Reject Write/Reply chunks with segcount 0"}]}}}