Re: [PATCH v2] RDMA/rxe: Validate inline data range in user WQEs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] RDMA/rxe: incomplete TOCTOU fix due to missing READ_ONCE()
--

commit e7e4b53005e1e5706321c684271dff347a0b85b9
Author: Jiale Yao <yaojiale02@163.com>

RDMA/rxe: Validate inline data range in user WQEs

This commit addresses a vulnerability where userspace can provide an
out-of-bounds sge_offset for an inline WQE in the mmap'd send queue ring.
It validates the offset and copies it to a local variable to prevent a
TOCTOU race.

Link: https://lore.kernel.org/all/20260708224534.1206-1-security@auditcode.ai/

> diff --git a/drivers/infiniband/sw/rxe/rxe_req.c b/drivers/infiniband/sw/rxe/rxe_req.c
> index 53f7c1e7fe55b..fd2f248a1f448 100644
> --- a/drivers/infiniband/sw/rxe/rxe_req.c
> +++ b/drivers/infiniband/sw/rxe/rxe_req.c

[ ... ]

> @@ -510,12 +511,19 @@ static int finish_packet(struct rxe_qp *qp, struct rxe_av *av,
>  
>  	if (pkt->mask & RXE_WRITE_OR_SEND_MASK) {
>  		if (wqe->wr.send_flags & IB_SEND_INLINE) {
> -			u8 *tmp = &wqe->dma.inline_data[wqe->dma.sge_offset];
> +			sge_offset = wqe->dma.sge_offset;
> +			if (unlikely(sge_offset > qp->sq.max_inline ||
> +				     payload >
> +				     qp->sq.max_inline - sge_offset)) {
> +				rxe_dbg_qp(qp, "invalid inline data range in send wqe\n");
> +				return -EINVAL;
> +			}
>  
> -			memcpy(payload_addr(pkt), tmp, payload);
> +			memcpy(payload_addr(pkt),
> +			       &wqe->dma.inline_data[sge_offset], payload);

[Severity: High]
Does this code still leave a TOCTOU window open?

In drivers/infiniband/sw/rxe/rxe_req.c:finish_packet(), the value of
wqe->dma.sge_offset is read from shared memory into the local variable
sge_offset using a standard assignment.

Without a READ_ONCE() wrapper, the compiler is free to optimize out the local
variable and emit multiple memory loads directly from the shared memory
pointer. If a local attacker modifies the mmap'd wqe->dma.sge_offset value
concurrently after the bounds check but before the memcpy executes, the
compiler might reload the modified value for the memcpy indexing.

Could this regression result in an out-of-bounds kernel memory read,
leading to sensitive information disclosure or a KASAN vmalloc-out-of-bounds
panic?

>  
>  			wqe->dma.resid -= payload;
> -			wqe->dma.sge_offset += payload;
> +			wqe->dma.sge_offset = sge_offset + payload;
>  		} else {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260926070403.3005250-1-yaojiale02@163.com?part=1