Re: [for-next v4 4/5] RDMA/ionic: add Shared receive queue (SRQ) support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] rdma/ionic: silent data loss when kernel polls SRQ-attached CQ
--

commit ccf1245b508acbe9a1128018da0500733eaed2c6
Author: Amit Kumar <a.k@amd.com>

RDMA/ionic: add Shared receive queue (SRQ) support

Implement device supported verb APIs for shared receive queue.
SRQ is supported for userspace only. ionic_create_srq() returns
-EOPNOTSUPP when there is no ucontext, so kernel ULPs cannot create an SRQ.

> diff --git a/drivers/infiniband/hw/ionic/ionic_datapath.c b/drivers/infiniband/hw/ionic/ionic_datapath.c
> index 522c6f08c9fdd..c5726c6bd5cb3 100644
> --- a/drivers/infiniband/hw/ionic/ionic_datapath.c
> +++ b/drivers/infiniband/hw/ionic/ionic_datapath.c

[ ... ]

> @@ -526,6 +526,12 @@ static int ionic_poll_vcq_cq(struct ionic_ibdev *dev,
>  
>  		switch (type) {
>  		case IONIC_V1_CQE_TYPE_RECV:
> +			if (qp->srq) {
> +				ibdev_dbg(&dev->ibdev,
> +					  "srq recv cqe for qp %u\n", qid);
> +				goto cq_next;
> +			}
> +

[Severity: Medium]
Does this logic in ionic_poll_vcq_cq result in silent data loss for SRQ
completions? 

If an unprivileged userspace application calls IB_USER_VERBS_CMD_POLL_CQ to
poll a memory-mapped CQ that receives completions for an SRQ-attached QP,
this block appears to process the CQE, skip it with goto cq_next, and free
the hardware slot without returning the completion to userspace.

>  			spin_lock(&qp->rq.lock);
>  			rc = ionic_poll_recv(dev, cq, qp, cqe, wc + npolled);

[Severity: High]
This is a pre-existing issue, but can the call to ionic_poll_recv here
trigger a NULL pointer dereference for userspace QPs?

If a userspace application calls IB_USER_VERBS_CMD_POLL_CQ to poll a CQ
containing completions for a userspace non-SRQ QP, ionic_poll_recv will
attempt to dereference qp->rq.meta[wqe_idx]:

drivers/infiniband/hw/ionic/ionic_datapath.c:ionic_poll_recv() {
    ...
    meta = &qp->rq.meta[wqe_idx];
    if (unlikely(meta->next != IONIC_META_POSTED)) {
    ...
}

Since rq.meta is explicitly set to NULL for userspace QPs during
initialization when udata is not NULL, this seems to lead to a kernel
crash upon accessing meta->next. Is this reachable by unprivileged
userspace applications?

>  			spin_unlock(&qp->rq.lock);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260930092111.3176738-1-abhijit.gangurde@amd.com?part=4