Re: [PATCH 0/2] RDMA/rxe: fix shared memory TOCTOU in receive path

[Tristan Madani <tristmd@gmail.com>]

On Tue, 19 May 2026, Jason Gunthorpe wrote:
> Simple misbehave is one thing, but if userspace can hack the kernel
> and gain control of it through this shared memory then we have to fix
> it.

The non-SRQ receive path in check_resource() sets qp->resp.wqe
directly into the shared mmap buffer:

    qp->resp.wqe = queue_head(qp->rq.queue, QUEUE_TYPE_FROM_CLIENT);

No copy, no validation of the WQE fields. Every subsequent access
to wqe->dma.num_sge, wqe->dma.sge[].lkey, and wqe->dma.sge[].addr
reads from memory that userspace can modify concurrently.

The concrete problem is in copy_data(), called via send_data_in().
It re-reads dma->num_sge from the shared buffer on every loop
iteration (the dma->cur_sge >= dma->num_sge bound check), and uses
sge->lkey for lookup_mr() and sge->addr to compute the iova for
rxe_mr_copy(). A concurrent thread can:

  1. Increase num_sge: the sge pointer walks past the WQE's
     allocated SGE slots into adjacent queue entries, and the
     kernel acts on whatever lkey/addr/length values it finds
     there -- all attacker-controlled through the same mmap.

  2. Swap sge[].lkey between iterations: redirect the MR lookup
     to a different memory region.

  3. Modify sge[].addr: shift the write target within the
     resolved MR.

The data being written is incoming packet payload (attacker-
controlled in loopback), direction is RXE_TO_MR_OBJ.

The SRQ path already handles this correctly: get_srq_wqe() copies
the WQE to kernel memory with memcpy() and validates num_sge
against max_sge before use. The comment there says "don't trust
user space data". The non-SRQ path has neither the copy nor the
validation.

The race window is not tight -- the shared pointer is set during
RESPST_CHK_RESOURCE and the fields are consumed across CHK_LENGTH
and EXECUTE before copy_data() runs.

I can provide a reproducer if that helps move the patches forward.

Tristan