Re: [PATCH rdma-next 02/10] RDMA/mana: Create and destroy kernel RC QPs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] mana: integer underflow when querying device max_send_sge bypasses IB core limits
--

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

RDMA/mana: Create and destroy kernel RC QPs

This commit implements kernel RC QP creation and destruction in the mana
driver. The feature adds support for extended-WQE and power-of-two-SQ queues
requiring support from the underlying hardware.

> diff --git a/drivers/infiniband/hw/mana/main.c b/drivers/infiniband/hw/mana/main.c
> --- a/drivers/infiniband/hw/mana/main.c
> +++ b/drivers/infiniband/hw/mana/main.c
> @@ -637,7 +637,8 @@ int mana_ib_query_device(struct ib_device *ibdev, struct ib_device_attr *props,
>  	props->max_qp = dev->adapter_caps.max_qp_count;
>  	props->max_qp_wr = dev->adapter_caps.max_qp_wr;
>  	props->device_cap_flags = IB_DEVICE_RC_RNR_NAK_GEN;
> -	props->max_send_sge = dev->adapter_caps.max_send_sge_count;
> +	/* Subtract 1 from max_send_sge to account for the reserved SGE */
> +	props->max_send_sge = dev->adapter_caps.max_send_sge_count - 1;

[Severity: Medium]
Is it possible for dev->adapter_caps.max_send_sge_count to be 0 when queried
from the device firmware?

If the device reports 0 for this capability, this unchecked subtraction could
wrap around and expose UINT_MAX as the maximum send SGE limit to the IB core
and userspace.

Could this lead to integer overflows in mana_ib_wqe_size() and under-allocated
DMA queues if a user requests an overly large SGE count based on this inflated
limit, ultimately causing out-of-bounds hardware memory accesses?

>  	props->max_recv_sge = dev->adapter_caps.max_recv_sge_count;
>  	props->max_sge_rd = dev->adapter_caps.max_recv_sge_count;
>  	props->max_cq = dev->adapter_caps.max_cq_count;

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