RDMA/rxe: Validate num_sge/cur_sge before indexing wqe->dma.sge[]
Get instant alerts when new vulnerabilities affect Linux - before attackers find them.
In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Validate num_sge/cur_sge before indexing wqe->dma.sge[] For a user QP, qp->sq.queue is a ring the application writes directly, so rxe_post_send() takes the is_user branch and only schedules send_task without validating the WQE. rxe_requester() consumes it in place via req_next_wqe() and calls copy_data(), which indexes &wqe->dma.sge[cur_sge] with the attacker-controlled num_sge/cur_sge. Only the kernel path bounds num_sge (validate_send_wr()); the user WQE is never checked, so a local unprivileged user can post a WQE with an out-of-range cur_sge or oversized num_sge and force an out-of-bounds read of the per-WQE sge array in copy_data() (vmalloc OOB read, local DoS). Bound num_sge to qp->sq.max_sge in rxe_requester() before use, the way get_srq_wqe() already guards SRQ entries, and bound cur_sge only when the WQE carries payload (dma.resid): copy_data() returns early on a zero-length copy before touching dma->sge[], so a zero-payload WQE -- the only kind a max_sge == 0 QP can post -- stays valid. Reproduced under KASAN; the vmalloc-out-of-bounds in copy_data() is gone.
Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.
No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.
Get alerted
Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.