Re: [PATCH rdma-next v2 06/14] net/smc: Look up the pnetid ib device within the net namespace

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Returning unreferenced device pointers from `smc_pnet_find_ib()` and `smc_pnet_find_smcd()` causes Use-After-Free vulnerabilities when devices are concurrently removed.
--

--- Patch [6]: [PATCH rdma-next v2 06/14] net/smc: Look up the pnetid ib device within the net namespace ---
commit 4529cf06709604767797679d2d489bb89001f950
Author: Jiri Pirko <jiri@nvidia.com>
Date:   Tue Jul 14 14:29:19 2026 +0000

    net/smc: Look up the pnetid ib device within the net namespace
    
    Scope smc_pnet_find_ib() to the caller's net namespace so pnetid setup
    cannot bind to a same-named RDMA device from another namespace once names
    become per-netns.

> diff --git a/net/smc/smc_pnet.c b/net/smc/smc_pnet.c
> index 63e286e2dfaa8..ff9c9c35cc2f5 100644
> --- a/net/smc/smc_pnet.c
> +++ b/net/smc/smc_pnet.c
> @@ -408,8 +413,8 @@ static int smc_pnet_add_eth(struct smc_pnettable *pnettable, struct net *net,
>  	return rc;
>  }
>  
> -static int smc_pnet_add_ib(struct smc_pnettable *pnettable, char *ib_name,
> -			   u8 ib_port, char *pnet_name)
> +static int smc_pnet_add_ib(struct smc_pnettable *pnettable, struct net *net,
> +			   char *ib_name, u8 ib_port, char *pnet_name)
>  {
>  	struct smc_pnetentry *tmp_pe, *new_pe;
>  	struct smc_ib_device *ib_dev;
> @@ -419,7 +424,7 @@ static int smc_pnet_add_ib(struct smc_pnettable *pnettable, char *ib_name,
>  	bool new_ibdev;
>  
>  	/* try to apply the pnetid to active devices */
> -	ib_dev = smc_pnet_find_ib(ib_name);
> +	ib_dev = smc_pnet_find_ib(net, ib_name);

[Severity: High]
This is a pre-existing issue, but can this lead to a use-after-free?

Looking at smc_pnet_find_ib(), it searches for an IB device while holding
smc_ib_devices.mutex, finds one, drops the lock, and returns a raw,
unreferenced ibdev pointer:

net/smc/smc_pnet.c:smc_pnet_find_ib() {
    ...
    mutex_unlock(&smc_ib_devices.mutex);
    return ibdev;
}

If an asynchronous device unregistration occurs immediately after the lock is
dropped, smc_ib_remove_dev() could acquire the mutex, remove the device from
the list, and free the smc_ib_device structure.

The caller (smc_pnet_add_ib) then dereferences the freed pointer locklessly
(e.g., when accessing ib_dev->ibdev->name for logging) or passes it to
smc_pnet_apply_ib(), which re-acquires the mutex and accesses fields of the
potentially freed device pointer.

Should smc_pnet_find_ib() take a reference on the device before dropping the
mutex?

>  	if (ib_dev) {
>  		ibdev_applied = smc_pnet_apply_ib(ib_dev, ib_port, pnet_name);
>  		if (ibdev_applied)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714142927.1298897-1-jiri@resnulli.us?part=6