Re: [PATCH rdma-next v2 04/10] RDMA/mana_ib: Maintain kernel RC QP state

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] RDMA/mana_ib: NULL pointer dereference when arming doorbell for userspace RC QPs
--

commit d94733697b534fa1d978860b21f69a9735157978
Author: Konstantin Taranov <kotaranov@microsoft.com>

RDMA/mana_ib: Maintain kernel RC QP state

This commit updates mana_ib_modify_qp_state() to support RC QPs and initialize
the packet, message, and frame counters. It also arms the requester receive
queue at the initial PSN so that a CQE is generated when the PSN is
acknowledged.

> diff --git a/drivers/infiniband/hw/mana/qp.c b/drivers/infiniband/hw/mana/qp.c
> index edaf03372cd81..74cf80074e54f 100644
> --- a/drivers/infiniband/hw/mana/qp.c
> +++ b/drivers/infiniband/hw/mana/qp.c
[ ... ]
> @@ -1044,8 +1051,19 @@ static void mana_ib_modify_qp_state(struct ib_qp *ibqp, struct ib_qp_attr *attr,
>  		}
>  	}
>  
> -	if (attr_mask & IB_QP_SQ_PSN)
> +	if (attr_mask & IB_QP_SQ_PSN) {
> +		qp->sq_ssn = 1;
> +		qp->sq_rsn = 1;
> +		qp->sq_fsn = 1;
>  		qp->sq_psn = attr->sq_psn;
> +		qp->pending_mmq_fence = false;
> +
> +		if (qp->ibqp.qp_type == IB_QPT_RC) {
> +			rq = qp->rc_qp.queues[MANA_RC_RECV_QUEUE_REQUESTER].kmem;
> +			mana_gd_wq_ring_doorbell_ext(mdev_to_gc(mdev), rq, attr->sq_psn,
> +						     SET_ARM_BIT, MANA_PSN_CLIENT_OFFSET);
> +		}
> +	}
>  }

[Severity: High]
Could this lead to a NULL pointer dereference when arming the doorbell for
userspace RC QPs?

When the RDMA Connection Manager (RDMA CM) handles connection establishment for
userspace RC QPs, it can call ib_modify_qp() with a NULL udata pointer. This
eventually invokes mana_ib_modify_qp_state().

Since udata is NULL during these kernel-driven CM transitions, the early return
check at the beginning of the function fails to distinguish userspace QPs, and
it incorrectly treats them as kernel QPs.

For userspace QPs, the kmem pointer fetched here is left uninitialized (NULL).
It is then passed to mana_gd_wq_ring_doorbell_ext(), which unconditionally
dereferences it when accessing queue->gdma_dev:

mana_gd_wq_ring_doorbell_ext()
    mana_gd_ring_doorbell(gc, queue->gdma_dev->doorbell, ...)

This can result in a kernel panic that can be triggered by unprivileged
userspace applications initiating or receiving an RDMA CM connection. This
issue does not appear to be fixed in subsequent patches in the series.

Is there another way to correctly identify userspace QPs during these CM
transitions so we avoid dereferencing an uninitialized kmem pointer?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261003064037.2092669-1-kotaranov@linux.microsoft.com?part=4