Re: [PATCH net-next] net/rds: restrict the rdma_cm ids to IB devices

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] rds: memory leak of rdma_cm_id in rds_ib_conn_path_connect error path
--

commit 09995cfa814e39bb6b39d83f2fc5b812b28b6fcc
Author: Allison Henderson <achender@kernel.org>

net/rds: restrict the rdma_cm ids to IB devices

This commit restricts the RDS RDMA connection IDs to IB devices by utilizing
the rdma_restrict_node_type API. It adds calls to this function during
listener initialization, probe check, and connection path setup to ensure
the CMA IDs are strictly bound to RDMA_NODE_IB_CA nodes.

> diff --git a/net/rds/ib_cm.c b/net/rds/ib_cm.c
> index 4feb0edc360c8..a859c252fd9a7 100644
> --- a/net/rds/ib_cm.c
> +++ b/net/rds/ib_cm.c
[ ... ]
> @@ -999,6 +999,16 @@ int rds_ib_conn_path_connect(struct rds_conn_path *cp)
>  		goto out;
>  	}
>  
> +	/* rds_ib_laddr_check() only vouched for the local address being
> +	 * on an IB device; the address resolution below picks the device
> +	 * on its own, so restrict it to the same kind.
> +	 */
> +	ret = rdma_restrict_node_type(ic->i_cm_id, RDMA_NODE_IB_CA);
> +	if (ret) {
> +		rdsdebug("rdma_restrict_node_type() failed: %d\n", ret);
> +		goto out;

[Severity: Low]
Does this error path leak the rdma_cm_id resource?

When rdma_restrict_node_type() fails here, the code jumps to the 'out'
label and returns without destroying the newly allocated ic->i_cm_id. By
contrast, if the subsequent rdma_resolve_addr() call fails, the code
explicitly cleans up with rdma_destroy_id(ic->i_cm_id) and sets it to NULL
before returning.

While rdma_restrict_node_type() currently deterministically returns 0 for a
newly allocated ID (since it is in the RDMA_CM_IDLE state and using a valid
node type), should this error path also clean up the ID to prevent future
resource leaks if the restriction logic changes?

> +	}
> +
>  	rdsdebug("created cm id %p for conn %p\n", ic->i_cm_id, conn);
>  
>  	if (ipv6_addr_v4mapped(&conn->c_faddr)) {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260917074108.174262-1-achender@kernel.org?part=1