CVE-2026-98365: RDMA/rxe: Fix integer overflow in mr_check_range() leading to OOB access
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix integer overflow in mrcheckrange() leading to OOB access
mrcheckrange() validates that [iova, iova+length) falls within the registered MR range using wraparound-prone arithmetic:
if (iova < mr->ibmr.iova || iova + length > mr->ibmr.iova + mr->ibmr.length)
A remote peer can craft an RDMA-Write/Read RETH so that iova + length wraps to 0 (e.g. iova=0xfffffffffffffff8, length=8), bypassing the check. rxemriovatoindex() then computes a huge index (int idx, only guarded by WARNON) and rxemrcopyxarray() dereferences mr->pageinfo[huge], causing an out-of-bounds read/write and a kernel oops that is triggerable by an unauthenticated remote peer.
Rewrite the check in overflow-safe form; the first two clauses guarantee that the subsequent subtractions do not underflow:
if (iova < mr->ibmr.iova || length > mr->ibmr.length || iova - mr->ibmr.iova > mr->ibmr.length - length)
With the fix, mrcheckrange() returns -EINVAL for the crafted iova and the responder reports REMOTEACCESSERROR instead of triggering the OOB.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.158.1-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.113-1Fixed in 7.2.12-1Fixed in 7.2.13-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1
Event History
Frequently Asked Questions
Who can exploit this issue?
An unauthenticated remote RDMA peer can trigger it by sending a crafted RDMA Read or Write request containing a RETH with values that cause the IOVA-plus-length calculation to wrap.
What is the practical impact of successful exploitation?
The crafted request can bypass memory-region range validation and lead to an out-of-bounds read or write in the kernel. The described result includes a kernel oops.
How can I tell whether a system has the fix behavior?
For the crafted out-of-range IOVA request, the fixed code rejects the range with -EINVAL and the responder reports REMOTE_ACCESS_ERROR rather than performing the out-of-bounds access.