Re: [PATCH rdma-rc v2 04/15] RDMA/bnxt_re: Avoid any race while handling the hash list of CQ

[Jason Gunthorpe <jgg@nvidia.com>]

On Mon, Jun 15, 2026 at 03:47:40PM -0700, Selvin Xavier wrote:
> Add/Delete to/from hash list needs to be synchronized with the traversing
> of the hash list. Add a mutex for this synchronization. Also add a
> reference for the CQ to avoid any usage of the CQ structures after the
> CQ is freed.

Arg, this is messed up like this because the driver didn't implement
the uapi properly:

> @@ -252,6 +255,7 @@ static int UVERBS_HANDLER(BNXT_RE_METHOD_GET_TOGGLE_MEM)(struct uverbs_attr_bund
>  			return -EINVAL;
>  
>  		addr = (u64)cq->uctx_cq_page;
> +		bnxt_re_put_cq(cq);
>  		break;

Passing in uobj's through anything but the normal UVERBS_ATTR_IDR is
completely wrong.

And now the security model is messed up because the broken
bnxt_re_search_for_cq() doesn't respect the uctx boundaries and the
userspace can pass in any cq belonging to any process for this
operation. That's illegal.

I said the same thing on the dbr patches and they were fixed to use

+       uobj = uverbs_attr_get_uobject(attrs, BNXT_RE_ALLOC_DBR_HANDLE);

Which is the correct way to reach into other objects and prevents
all of these bugs.

Fixing this by adding more mess to the driver isn't right, you need to
rely on the uobject system to do this. Once you find the driver object
you'll need to call some new uobject function to validate and lock it
properly using object locking. Do not add new refcounts and
completions.

Jason