Re: [PATCH rdma-next 21/23] RDMA/mlx5: Clamp log_max_* shifts in query_device and ucontext paths

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] RDMA/mlx5: integer overflow and size truncation in mlx5_ib_create_srq()
--

commit 9361613960626bd9707489f3ac7caf042edc2d19
Author: Yishai Hadas <yishaih@nvidia.com>

RDMA/mlx5: Clamp log_max_* shifts in query_device and ucontext paths

This commit replaces open-coded shifts of 8-bit log_max_* and log_pg_sz
firmware capabilities with MLX5_CAP_GEN_LOGSZ_U32() and
MLX5_CAP_GEN_LOGSZ_U64() in device, port, ucontext, and SRQ paths, and
saturates products that can now exceed 32 bits.

> diff --git a/drivers/infiniband/hw/mlx5/srq.c b/drivers/infiniband/hw/mlx5/srq.c
> index 6a4a937d97ce9..3fbb0eaf12558 100644
> --- a/drivers/infiniband/hw/mlx5/srq.c
> +++ b/drivers/infiniband/hw/mlx5/srq.c
> @@ -198,7 +198,7 @@ int mlx5_ib_create_srq(struct ib_srq *ib_srq,
>  	size_t buf_size;
>  	int err;
>  	struct mlx5_srq_attr in = {};
> -	__u32 max_srq_wqes = 1 << MLX5_CAP_GEN(dev->mdev, log_max_srq_sz);
> +	__u32 max_srq_wqes = MLX5_CAP_GEN_LOGSZ_U32(dev->mdev, log_max_srq_sz);
>  	__u32 max_sge_sz =  MLX5_CAP_GEN(dev->mdev, max_wqe_sz_rq) /
>  			    sizeof(struct mlx5_wqe_data_seg);

[Severity: High]
With MLX5_CAP_GEN_LOGSZ_U32(), max_srq_wqes can now reach 2^31 (0x80000000U)
when the firmware reports log_max_srq_sz >= 31, which allows
init_attr->attr.max_wr values in [0x40000000, 0x7fffffff] to pass the
init_attr->attr.max_wr >= max_srq_wqes check in mlx5_ib_create_srq().

Can this overflow srq->msrq.max and truncate buf_size later in
mlx5_ib_create_srq()?

drivers/infiniband/hw/mlx5/srq.c:mlx5_ib_create_srq() {
	...
	srq->msrq.max    = roundup_pow_of_two(init_attr->attr.max_wr + 1);
	...
	buf_size = srq->msrq.max * desc_size;
	if (buf_size < desc_size)
		return -EINVAL;

	in.type = init_attr->srq_type;

	if (udata)
		err = create_srq_user(ib_srq->pd, srq, &in, udata, buf_size);
	else
		err = create_srq_kernel(dev, srq, &in, buf_size);
	...
}

In struct mlx5_core_srq (drivers/infiniband/hw/mlx5/srq.h), max is a signed
int:

	int max;

When init_attr->attr.max_wr is in [2^30, 2^31 - 1],
roundup_pow_of_two(init_attr->attr.max_wr + 1) evaluates to 2^31, which
overflows srq->msrq.max to INT_MIN. On 64-bit platforms,
srq->msrq.max * desc_size sign-extends srq->msrq.max to size_t before
multiplying by desc_size (a power of two >= 32), producing a large non-zero
size_t (for example, 0xfffffff000000000UL when desc_size == 32) that passes
buf_size < desc_size.

Even when log_max_srq_sz is in [26, 30] and srq->msrq.max stays positive
(e.g. in [2^26, 2^30]), size_t buf_size is >= 2^31 and is passed to
create_srq_user() or create_srq_kernel(), both of which take int buf_size:

	static int create_srq_user(struct ib_pd *pd, struct mlx5_ib_srq *srq,
				   struct mlx5_srq_attr *in,
				   struct ib_udata *udata, int buf_size)

	static int create_srq_kernel(struct mlx5_ib_dev *dev, struct mlx5_ib_srq *srq,
				     struct mlx5_srq_attr *in, int buf_size)

This truncates buf_size to 0 (when buf_size is a multiple of 2^32) or a
negative int.

In mlx5_ib_create_srq() -> create_srq_user(), buf_size == 0 passes
min_size = 0 to ib_umem_get_attr_or_va(), bypassing the minimum buffer size
check on the UVERBS_ATTR_CREATE_SRQ_BUF_UMEM path; then
in.log_size = ilog2(srq->msrq.max) on a negative srq->msrq.max yields 63,
and mlx5_cmd_create_srq() -> create_srq_split() -> create_rmp_cmd() ->
get_pas_size() executes an undefined shift:

	u32 rq_sz = 1 << (log_srq_size + 4 + log_rq_stride);

followed by a WARN_ON in __set_srq_page_size().

In mlx5_ib_create_srq() -> create_srq_kernel(), buf_size == 0 causes
mlx5_frag_buf_alloc_node() to allocate 0 pages (setting
srq->buf.frags = ZERO_SIZE_PTR) and return 0, so the WQE initialization loop
in create_srq_kernel() dereferences ZERO_SIZE_PTR when srq->msrq.max > 0 (or
underflows srq->tail = srq->msrq.max - 1 when srq->msrq.max == INT_MIN).

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261103163949.1554-1-yishaih@nvidia.com?part=21