CVE-2026-92525: RDMA/rxe: Validate num_sge/cur_sge before indexing wqe->dma.sge[]
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Validate numsge/cursge before indexing wqe->dma.sge[]
For a user QP, qp->sq.queue is a ring the application writes directly, so rxepostsend() takes the isuser branch and only schedules sendtask without validating the WQE. rxerequester() consumes it in place via reqnextwqe() and calls copydata(), which indexes &wqe->dma.sge[cursge] with the attacker-controlled numsge/cursge. Only the kernel path bounds numsge (validatesendwr()); the user WQE is never checked, so a local unprivileged user can post a WQE with an out-of-range cursge or oversized numsge and force an out-of-bounds read of the per-WQE sge array in copydata() (vmalloc OOB read, local DoS).
Bound numsge to qp->sq.maxsge in rxerequester() before use, the way getsrqwqe() already guards SRQ entries, and bound cursge only when the WQE carries payload (dma.resid): copydata() returns early on a zero-length copy before touching dma->sge[], so a zero-payload WQE -- the only kind a maxsge == 0 QP can post -- stays valid.
Reproduced under KASAN; the vmalloc-out-of-bounds in copydata() is gone.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the resolved fix so that the kernel path bounds num_sge (via validate_send_wr()) and bounds/validates cur_sge in rxe_requester() before using wqe->dma.sge[cur_sge] / copy_data() to prevent vmalloc out-of-bounds reads from attacker-controlled WQEs.
Linux kernel RDMA/rxe (rxe_requester / validate_send_wr path) Validate bounds for num_sge and cur_sge before indexing wqe->dma.sge[] = enabled
Event History
Frequently Asked Questions
Who can trigger this issue?
A local unprivileged user that can use an RXE user queue pair can craft a work queue entry with an oversized num_sge or out-of-range cur_sge. The affected queue is written directly by the application, so the malformed entry bypasses the validation applied to kernel-originated work requests.
What is the practical impact?
Malformed SGE indexes can cause an out-of-bounds read of the per-WQE SGE array in copy_data(). The reported consequence is a local denial of service through a vmalloc out-of-bounds read.
Are all malformed work queue entries affected?
The cur_sge value is relevant only when the WQE has payload, indicated by dma.resid, because copy_data() returns before accessing the SGE array for a zero-length copy. A QP with max_sge set to zero can post only zero-payload WQEs, which remain valid under the fix.
What validation does the resolved version add?
It bounds num_sge against qp->sq.max_sge in rxe_requester() before the value is used, and bounds cur_sge when the WQE carries payload. This prevents indexing wqe->dma.sge[] with attacker-controlled out-of-range values.