Re: [PATCH v3] RDMA/rxe: Sanitize receive WQE in local buffer

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] Copying into the inner `wqe` field triggers a FORTIFY_SOURCE field-spanning write WARN_ONCE or panic.

Pre-existing issues:
- [Critical] Double-fetch TOCTOU vulnerability in the send path (`rxe_req.c`) leading to out-of-bounds memory access.
--

commit 5c427e8b4bbe51e8f334533fce0d0db77db27960
Author: Nicolas Morey <nmorey@suse.com>

RDMA/rxe: Sanitize receive WQE in local buffer

This patch sanitizes receive work queue elements by copying them to a local
buffer and validating their fields. This addresses TOCTOU races and
out-of-bounds accesses during the receive path.

> diff --git a/drivers/infiniband/sw/rxe/rxe_resp.c b/drivers/infiniband/sw/rxe/rxe_resp.c
> --- a/drivers/infiniband/sw/rxe/rxe_resp.c
> +++ b/drivers/infiniband/sw/rxe/rxe_resp.c
[ ... ]
> @@ -257,6 +257,47 @@ static enum resp_states check_op_valid(struct rxe_qp *qp,
>  	return RESPST_CHK_RESOURCE;
>  }
>  
> +static enum resp_states recv_wqe_sanitize(struct rxe_qp *qp,
> +					struct rxe_recv_wqe *kernel_wqe,
> +					struct rxe_recv_wqe *user_wqe,
> +					int max_sge)
> +{
[ ... ]
> +	size = struct_size(user_wqe, dma.sge, num_sge);
> +	memcpy(kernel_wqe, user_wqe, size);

[Severity: High]
Will this memcpy trigger a FORTIFY_SOURCE warning or kernel panic due to a
field-spanning write?

When recv_wqe_sanitize is called from get_srq_wqe, it is passed a pointer to
the inner wqe sub-object:

> +	err = recv_wqe_sanitize(qp, &qp->resp.srq_wqe.wqe, wqe, srq->rq.max_sge);

Because the destination pointer points specifically to the nested wqe struct
within the larger srq_wqe struct, the compiler evaluates the size of this
object to exactly 40 bytes. When memcpy attempts to write up to
40 + 16 * max_sge bytes, it violates this strict bounds check, resulting in a
denial of service on the receive path.

[ ... ]

[Severity: Critical]
This is a pre-existing issue, but I noticed the symmetric send path appears
to suffer from a very similar TOCTOU vulnerability that might lead to an
out-of-bounds memory access.

In rxe_req.c, rxe_requester performs a bounds check on cur_sge while the
data is still in shared memory:

        if (unlikely(wqe->dma.num_sge > qp->sq.max_sge ||
                     (wqe->dma.resid &&
                      wqe->dma.cur_sge >= qp->sq.max_sge))) {

However, a malicious user could potentially overwrite cur_sge immediately
after this check. Later, copy_data in rxe_mr.c re-fetches cur_sge directly
from the shared memory and uses it as an array index:

        struct rxe_sge          *sge    = &dma->sge[dma->cur_sge];

Could this bypass the validation and read memory outside the wqe if the
value is mutated between the check and the use?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260910083712.1595862-1-nmorey@suse.com?part=1