CVE-2026-89533: svcrdma: Fix offset arithmetic in read_chunk_range

Published Sep 11, 2026
·
Updated

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

Sep 11, 2026
CVE Published
via MITRE·07:44 PM
Data Sourced
via MITRE·07:44 PM
Description

Frequently Asked Questions

1

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.

2

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.

3

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203