Linux RDMA and InfiniBand development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Tristan Madani" <tristmd@gmail.com>
Cc: linux-rdma@vger.kernel.org
Subject: Re: [PATCH v8 2/2] RDMA/rxe: copy send WQE to kernel buffer in completer path
Date: Fri, 30 Oct 2026 17:13:55 +0000	[thread overview]
Message-ID: <sashiko-outbox-191314@kernel.org> (raw)
In-Reply-To: <20261030165044.2799619-3-tristan@talencesecurity.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] RDMA/rxe: stale comp_wqe cache across RNR retry in rxe_completer()
- [High] RDMA/rxe: unvalidated shared state and status in get_wqe() hit WARN_ON_ONCE
--

commit 249927ff74c8311cd6d2280c79ed9338f558aefd
Author: Tristan Madani <tristmd@gmail.com>

RDMA/rxe: copy send WQE to kernel buffer in completer path

This commit copies send WQEs from the userspace-mapped shared queue into a
completer-private buffer in get_wqe() to prevent TOCTOU races, reuses the
local copy while processing multi-packet responses, validates the opcode and
SGE fields, and writes back DMA progress on completion and retry.

> diff --git a/drivers/infiniband/sw/rxe/rxe_comp.c b/drivers/infiniband/sw/rxe/rxe_comp.c
> index 1390e861bd1d7..b8bc710dc75e9 100644
> --- a/drivers/infiniband/sw/rxe/rxe_comp.c
> +++ b/drivers/infiniband/sw/rxe/rxe_comp.c
> @@ -137,22 +137,87 @@ void rxe_comp_queue_pkt(struct rxe_qp *qp, struct sk_buff *skb)

[ ... ]

> +	/* Pairs with smp_store_release() in rxe_req_writeback_wqe() */
> +	state = smp_load_acquire(&wqe->state);
> +	if (state == wqe_state_posted) {
> +		*wqe_p = NULL;
> +		return pkt ? COMPST_DONE : COMPST_EXIT;
> +	}
> +
> +	/* Reuse existing local copy if still processing same WQE
> +	 * with unchanged state (preserves DMA progress for multi-packet ops)
> +	 */
> +	if (qp->comp.comp_wqe_valid && qp->comp.shared_wqe == wqe &&
> +	    qp->comp.comp_wqe.wqe.state == state) {
> +		wqe = &qp->comp.comp_wqe.wqe;
> +		*wqe_p = wqe;
> +		goto check_state;
> +	}
> +
> +	/* Copy shared WQE to kernel-private buffer.
> +	 * Copy size matches the queue element data area.
> +	 */
> +	qp->comp.shared_wqe = wqe;
> +	memcpy(&qp->comp.comp_wqe, wqe,
> +	       sizeof(*wqe) + max_t(int,
> +				qp->sq.max_sge * sizeof(struct ib_sge),
> +				qp->sq.max_inline));
> +	qp->comp.comp_wqe_valid = true;
> +
> +	/* Preserve the state we observed via smp_load_acquire()
> +	 * since memcpy may have overwritten it with a stale read.
> +	 */
> +	qp->comp.comp_wqe.wqe.state = state;
> +
> +	/* Reject corrupted opcode or SGE indices, error the QP */
> +	if (unlikely(qp->comp.comp_wqe.wqe.wr.opcode > IB_WR_REG_MR) ||
> +	    qp->comp.comp_wqe.wqe.dma.num_sge > qp->sq.max_sge ||
> +	    (qp->comp.comp_wqe.wqe.dma.resid &&
> +	     qp->comp.comp_wqe.wqe.dma.cur_sge >= qp->sq.max_sge)) {
> +		qp->comp.comp_wqe.wqe.status = IB_WC_LOC_QP_OP_ERR;
> +		wqe = &qp->comp.comp_wqe.wqe;
> +		*wqe_p = wqe;
> +		return COMPST_ERROR;
> +	}
> +
> +	wqe = &qp->comp.comp_wqe.wqe;
> +	*wqe_p = wqe;
>  
> +check_state:
>  	/* WQE does not require an ack */
>  	if (wqe->state == wqe_state_done)
>  		return COMPST_COMP_WQE;

[Severity: High]
Can userspace trigger the WARN_ON_ONCE(wqe->status == IB_WC_SUCCESS) in
rxe_completer() or force get_wqe() to overwrite qp->comp.comp_wqe mid-read?

In get_wqe() in drivers/infiniband/sw/rxe/rxe_comp.c, state is loaded from the
userspace-mapped shared queue and wqe (including wqe->status) is copied into
qp->comp.comp_wqe. At check_state, get_wqe() then checks:

	/* WQE caused an error */
	if (wqe->state == wqe_state_error)
		return COMPST_ERROR;

When COMPST_ERROR runs in rxe_completer():

		case COMPST_ERROR:
			WARN_ON_ONCE(wqe->status == IB_WC_SUCCESS);
			do_complete(qp, wqe);
			rxe_qp_error(qp);
			goto exit;

If userspace writes wqe->state = wqe_state_error with wqe->status =
IB_WC_SUCCESS in the mmap'd send queue ring (or overwrites shared->status = 0
after rxe_req_writeback_wqe() sets wqe_state_error), get_wqe() returns
COMPST_ERROR without ensuring wqe->status != IB_WC_SUCCESS. This hits
WARN_ON_ONCE(wqe->status == IB_WC_SUCCESS) in rxe_completer() and causes
do_complete() to see IB_WC_SUCCESS, skipping mandatory error CQE generation
for unsignaled WRs.

In addition, get_wqe() only reuses qp->comp.comp_wqe when
qp->comp.comp_wqe.wqe.state == state. If userspace toggles wqe->state in the
shared ring between response packets of a multi-packet RDMA READ (for example
between wqe_state_pending and wqe_state_processing), won't get_wqe() discard
the cached local copy and overwrite qp->comp.comp_wqe from untrusted shared
memory on each packet?

[ ... ]

> @@ -809,6 +878,8 @@ int rxe_completer(struct rxe_qp *qp)
>  				 * rnr timer has fired
>  				 */
>  				qp->req.wait_for_rnr_timer = 1;
> +				rxe_comp_writeback_wqe(qp);
> +				qp->comp.comp_wqe_valid = false;
>  				rxe_dbg_qp(qp, "set rnr nak timer\n");

[Severity: High]
Can qp->comp.comp_wqe become stale across an RNR retry if rxe_completer()
runs again before rnr_nak_timer fires?

In rxe_completer() in drivers/infiniband/sw/rxe/rxe_comp.c, COMPST_RNR_RETRY
sets qp->req.wait_for_rnr_timer = 1, writes back and invalidates
qp->comp.comp_wqe_valid, and arms qp->rnr_nak_timer, while qp->req.need_retry
remains 0 until rnr_nak_timer() fires.

However, the early exit check at the top of rxe_completer() only checks
qp->req.need_retry:

	if (qp->req.need_retry)
		goto exit;

If rxe_completer() runs again before rnr_nak_timer expires (for example on
the next iteration of rxe_sender(), or when send_task is scheduled by
rxe_post_send(), rxe_comp_queue_pkt(), or rxe_skb_tx_dtor()), it enters
COMPST_GET_WQE -> get_wqe(). Because req_retry() has not run yet, the shared
WQE still has state == wqe_state_pending (or wqe_state_processing), so
get_wqe() copies the pre-retry WQE (with its old first_psn and last_psn) back
into qp->comp.comp_wqe and sets qp->comp.comp_wqe_valid = true.

When rnr_nak_timer() later fires, rxe_requester() in
drivers/infiniband/sw/rxe/rxe_req.c runs:

	if (unlikely(qp->req.need_retry && !qp->req.wait_for_rnr_timer)) {
		req_retry(qp);
		qp->req.need_retry = 0;
		qp->req.send_wqe_valid = false;
	}

This does not clear qp->comp.comp_wqe_valid, and rxe_requester() immediately
retransmits the WQE with updated PSN bounds and sets shared->state back to
wqe_state_pending. When the retried response arrives, get_wqe() sees
qp->comp.comp_wqe_valid == true, qp->comp.shared_wqe == wqe, and
qp->comp.comp_wqe.wqe.state == state (both wqe_state_pending), so it reuses
the stale pre-retry comp_wqe. For a partially completed multi-packet RDMA
READ where first_psn advanced on retry, won't check_ack() compare pkt->psn
against the stale wqe->first_psn and transition the QP to COMPST_ERROR?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261030165044.2799619-1-tristan@talencesecurity.com?part=2

      reply	other threads:[~2026-10-30 17:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-30 16:50 [PATCH v8 0/2] RDMA/rxe: copy send WQE to kernel buffer before processing Tristan Madani
2026-10-30 16:50 ` [PATCH v8 1/2] " Tristan Madani
2026-10-30 17:04   ` sashiko-bot
2026-10-30 16:50 ` [PATCH v8 2/2] RDMA/rxe: copy send WQE to kernel buffer in completer path Tristan Madani
2026-10-30 17:13   ` sashiko-bot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-191314@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tristmd@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox