CVE-2026-89533: svcrdma: Fix offset arithmetic in read_chunk_range
In the Linux kernel, the following vulnerability has been resolved:
svcrdma: Fix offset arithmetic in readchunkrange
svcrdmareadchunkrange() walks a Read chunk's segment list to build a sub-range starting at byte offset and spanning length bytes for a Position-Zero or Call chunk. Two arithmetic defects in the per-segment loop produce wrong DMA lengths and a u32 underflow:
pclforeachsegment(segment, chunk) { if (offset > segment->rslength) { offset -= segment->rslength; continue; }
dummy.rshandle = segment->rshandle; dummy.rslength = mint(u32, length, segment->rslength) - offset; dummy.rsoffset = segment->rsoffset + offset;
First, the skip predicate uses '>' instead of '>='. When offset equals the segment's full rslength, the segment is fully consumed and should be skipped, but the loop falls through into the body. The resulting dummy.rslength is mint(u32, length, rslength) - rslength, which underflows to a near-UINTMAX u32 when length is smaller than rslength, or is zero otherwise.
Second, the length formula subtracts offset from the mint() result rather than from segment->rslength before the cap. For offset > 0 the segment's residual is rslength - offset, not rslength, so the cap must be applied to the residual. With the current bracketing, whenever length is smaller than rslength - offset the per-segment length becomes length - offset instead of length, silently dropping offset bytes from the rebuilt chunk. Combined with the boundary case above it also enables the u32 underflow path, which propagates a huge nrbvec into svcrdmabuildreadsegment() and a multi-MiB kmallocarraynode() in svcrdmagetrwctxt().
Additionally, svcrdmareadcallchunk() can invoke this function with length == 0 when the last Read chunk ends exactly at the end of the Call chunk. With the corrected >= predicate, every segment is skipped and the function returns the initial -EINVAL, rejecting a valid request. Return success immediately when length is zero. Also break out of the loop once length is fully consumed to avoid passing zero-length segments to svcrdmabuildreadsegment().
Fix by using '>=' so a fully-consumed segment is skipped, by moving '- offset' inside mint() so the cap is applied to the segment's residual length, by returning success for zero-length requests, and by stopping iteration when the requested range has been consumed.
Event History
Frequently Asked Questions
Which RDMA requests are relevant to this issue?
The affected logic builds sub-ranges for Position-Zero or Call chunks in the svcrdma read-chunk path. Systems not using that path are not described as affected by the available information.
What conditions lead to the arithmetic errors?
One error occurs when the requested byte offset exactly equals a segment's rs_length, because that fully consumed segment is not skipped. Another occurs when a nonzero offset is applied within a segment, because the length cap is applied before accounting for the segment offset.
How can I check whether source code includes the vulnerable logic?
The vulnerable loop skips a segment only when offset is greater than rs_length and calculates rs_length as min(length, segment rs_length) minus offset. This can produce an oversized unsigned length through u32 underflow or an incorrect DMA length.