CVE-2026-93228 in Linux
Summary
by MITRE • 09/24/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/24/2026
The Linux kernel's Sun RPC over RDMA implementation contained a logic flaw in the handling of Write and Reply chunk descriptors within the XDR decoding layer. Specifically, the function xdr_check_write_chunk() was designed to validate that the segment count field did not exceed the maximum allowed page limit defined by rc_maxpages. However, this validation failed to enforce a lower bound, allowing peers to submit chunks with a segcount value of zero. When such a malformed frame is processed, the subsequent call to xdr_inline_decode passes a length argument of zero, which returns the current cursor without advancing it and evaluates as true for success. Consequently, pcl_alloc_write() proceeds to allocate memory and link a struct svc_rdma_chunk object with a ch_segcount of zero onto either the rc_write_pcl or rc_reply_pcl lists. This behavior violates the protocol semantics defined in RFC 8166, which dictates that Write and Reply chunks must describe valid remote buffers; a segment count of zero implies no buffer is being accessed, rendering such frames meaningless for legitimate client operations.
While an earlier patch in the same series had modified pcl_for_each_segment() to safely handle cases where ch_segcount equals zero, preventing immediate memory corruption or infinite loops during iteration, this mitigation did not address the root cause at the input validation boundary. The presence of degenerate zero-segment chunks on the parsed chunk lists remains undesirable from a defense-in-depth perspective. By allowing these invalid structures into the internal data structures, there is a risk that future code changes might directly access ch_segments without proper safeguards, potentially leading to unexpected behavior or vulnerabilities in consumers that assume valid segment arrays. Rejecting the malformed frame at the decode stage ensures that such degenerate chunks are filtered out before they can be linked into any operational lists, thereby maintaining data integrity and preventing potential exploitation vectors related to invalid memory references or logic errors downstream.
To resolve this issue, two primary technical adjustments were implemented within the kernel source code. First, the validation logic in xdr_check_write_chunk() was updated to explicitly reject chunks where segcount is zero, ensuring that only valid non-zero segment counts are processed further down the stack. This change aligns with standard input validation practices and prevents invalid protocol states from entering the system's core processing loops. Second, the order of operations within pcl_alloc_write() was reordered so that list_add_tail(), which links the chunk structure to the parsed lists, occurs only after the segment array has been fully populated. Previously, chunks were added to the list before their internal data structures were completely filled, creating a window where an incomplete or malformed chunk could be observed by concurrent consumers if validation logic were weakened in future updates. This reordering ensures that only fully validated and populated chunks are ever exposed to other parts of the kernel subsystem.
From a security taxonomy perspective, this vulnerability is classified under CWE-20: Improper Input Validation, as the system failed to verify that input data met expected constraints regarding segment counts. The attack vector involves sending specially crafted RDMA messages from a peer, which falls under ATT&CK technique T1498: Network Denial of Service if exploited to cause resource exhaustion or unexpected state changes in the kernel's RPC service layer. Although no legitimate client is affected by this flaw because RFC 8166 does not define meaning for zero-segment chunks, the vulnerability represents a deviation from strict protocol compliance and robustness standards. Mitigation involves applying the upstream Linux kernel patch that enforces the lower bound on segcount and reorders list insertion logic. System administrators should ensure their kernels are updated to versions containing this fix to maintain the integrity of RDMA-based RPC services and prevent potential abuse through malformed network frames.