Re: [PATCH] RDMA/rxe: validate cur_sge on the receive path before indexing dma->sge[]

[sashiko-bot@kernel.org]

> A user QP's receive queue is an mmap'd ring: the user provider
> writes the WQEs and post_recv does not touch them, so every field of
> struct rxe_recv_wqe is attacker controlled. When the responder takes
> a WQE it validates only dma.num_sge (rxe_get_recv_wqe() /
> get_srq_wqe()); dma.cur_sge, dma.sge_offset and dma.resid are copied
> into qp->resp.srq_wqe unchecked.
> 
> copy_data() then uses cur_sge as an index immediately --
> 	struct rxe_sge *sge = &dma->sge[dma->cur_sge];
> -- and dereferences it (sge->length) before the in-loop
> "dma->cur_sge >= dma->num_sge" test, which only runs after the first
> sge++. cur_sge is a u32, so this reads far out of bounds of the
> RXE_MAX_SGE-entry dma->sge[] embedded in the kmalloc-2k struct
> rxe_qp: an information leak (the out-of-bounds sge->length is
> recoverable through the work-completion status) and a DoS. The send
> queue already got this check in
> commit 126c757e4cd4 ("RDMA/rxe: Validate num_sge/cur_sge before indexing wqe->dma.sge[]");
> the receive path did not.
> 
> Reject an out-of-range cur_sge in copy_data() before the first sge
> dereference. This also covers the send retry path and is harmless to
> the kernel ULP path, which always sets cur_sge = 0.
> 
> Fixes: 8700e3e7c485 ("Soft RoCE driver")
> Signed-off-by: Youngsung Ahn <ays511.kr@gmail.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260930180119.2497360-1-ays511.kr@gmail.com?part=1