PT-2026-90248 · Linux · Linux

CVE-2026-89532

·

Published

2026-09-11

·

Updated

2026-09-11

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
svcrdma: Fix pcl for each segment for empty chunks
When a parsed chunk list contains a chunk whose ch segcount is zero, pcl for each segment computes its inclusive upper bound as &chunk->ch segments[ch segcount - 1]. ch segcount is u32, so the subtraction wraps to 0xFFFFFFFF and the bound lands far past the ch segments flex array. The loop body then walks unrelated memory at sizeof(struct svc rdma segment) stride until it faults.
A zero-segcount chunk is reachable from the wire: xdr check write chunk() only rejects segcount values greater than rc maxpages, and pcl alloc write() links a freshly allocated chunk onto rc write pcl/rc reply pcl before its segment-fill loop runs, so a Write or Reply chunk advertising zero segments leaves ch segcount == 0 on the list. When the transport has negotiated Send-With-Invalidate, svc rdma get inv rkey() iterates all four PCLs with pcl for each segment and dereferences segment->rs handle on each iteration, turning the underflow into an out-of-bounds read and a general protection fault.
xdr check write list / xdr check reply chunk pcl alloc write() chunk = pcl alloc chunk(...) /* ch segcount = 0 / list add tail(&chunk->ch list, &pcl->cl chunks) / fill loop iterates zero times for wire segcount 0 */
svc rdma get inv rkey() pcl for each chunk(rc write pcl) pcl for each segment(segment, chunk) pos <= &ch segments[0u - 1u] /* 0xFFFFFFFF / segment->rs handle / OOB read -> GPF */
Fix by switching the macro to a half-open upper bound that uses ch segcount directly. For ch segcount == 0 the loop start equals the loop end and the body is skipped; for ch segcount > 0 the iteration range is unchanged. All six existing call sites in net/sunrpc/xprtrdma/svc rdma recvfrom.c and net/sunrpc/xprtrdma/svc rdma rw.c remain correct under the new bound, so no caller changes are needed.
Found an issue in the description? Have something to add? Feel free to write us 👾

Related Identifiers

CVE-2026-89532

Affected Products

Linux