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

[Leon Romanovsky <leon@kernel.org>]

On Wed, Sep 30, 2026 at 05:34:55PM +0200, Greg KH wrote:
> On Thu, Oct 01, 2026 at 12:15:52AM +0900, AYS wrote:
> > 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; 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>
> 
> Does not match the "From:" line :(
> 
> No cc: stable?

No need to CC stable@ on RXE patches; I will remove it when applying them anyway.
Nothing urgent here.

Thanks

> 
> No Assisted-by: line?
> 
> thanks,
> 
> greg k-h
>