All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jiri Pirko" <jiri@resnulli.us>
Cc: "Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Heiko Carstens" <hca@linux.ibm.com>,
	tj@kernel.org, mkoutny@suse.com, hannes@cmpxchg.org,
	linux-s390@vger.kernel.org, "Vasily Gorbik" <gor@linux.ibm.com>
Subject: Re: [PATCH rdma-next 06/13] net/smc: Look up the pnetid ib device within the net namespace
Date: Fri, 10 Jul 2026 09:56:28 +0000	[thread overview]
Message-ID: <20260710095628.C5FB51F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260709095532.855647-7-jiri@resnulli.us>

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

Pre-existing issues:
- [High] Pre-existing TOCTOU and Use-After-Free race where `smc_pnet_find_ib()` and `smc_pnet_find_smcd()` return un-refcounted device pointers.
- [High] Pre-existing Use-After-Free during SMC connection setup due to un-refcounted `ib_dev` pointer in `smc_init_info`.
--

--- Patch [6]: [PATCH rdma-next 06/13] net/smc: Look up the pnetid ib device within the net namespace ---
commit d209b8afd09f2213c9477f5a717fdf012a7c2077
Author: Jiri Pirko <jiri@resnulli.us>

net/smc: Look up the pnetid ib device within the net namespace

This commit scopes smc_pnet_find_ib() to the caller's net namespace. It
ensures that pnetid setup cannot bind to a same-named RDMA device from
another namespace.

> 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
> @@ -304,13 +304,18 @@ static bool smc_pnetid_valid(const char *pnet_name, char *pnetid)
>  	return true;
>  }
>  
> -/* Find an infiniband device by a given name. The device might not exist. */
> -static struct smc_ib_device *smc_pnet_find_ib(char *ib_name)
> +/*
> + * Find an infiniband device by a given name, restricted to the devices
> + * accessible from @net. The device might not exist.
> + */
> +static struct smc_ib_device *smc_pnet_find_ib(struct net *net, char *ib_name)
>  {
>  	struct smc_ib_device *ibdev;
>  
>  	mutex_lock(&smc_ib_devices.mutex);
>  	list_for_each_entry(ibdev, &smc_ib_devices.list, list) {
> +		if (!rdma_dev_access_netns(ibdev->ibdev, net))
> +			continue;

[ ... ]

> @@ -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);
>  	if (ib_dev) {
>  		ibdev_applied = smc_pnet_apply_ib(ib_dev, ib_port, pnet_name);
>  		if (ibdev_applied)

[Severity: High]
This isn't a bug introduced by this patch, but smc_pnet_find_ib() in
net/smc/smc_pnet.c appears to return an un-refcounted device pointer.

If a user configures a PNETID for an IB or SMCD device via netlink and calls
smc_pnet_add_ib(), it locates the device in the global list while holding
smc_ib_devices.mutex. However, smc_pnet_find_ib() returns the raw pointer
after dropping the mutex.

If the device is concurrently hot-unplugged, smc_ib_remove_dev() or
smcd_unregister_dev() will acquire the mutex, remove the device from the
list, and kfree() the device structure.

Could the original netlink thread then continue execution and dereference the
now-freed pointer inside smc_pnet_apply_ib() or when printing
ib_dev->ibdev->name?

[Severity: High]
This is another pre-existing issue in net/smc/smc_pnet.c related to
un-refcounted pointers, but it happens during connection setup.

When a user calls connect() on an AF_SMC socket,
_smc_pnet_find_roce_by_pnetid() locates an active IB device while holding
smc_ib_devices.mutex, and stores its pointer in the smc_init_info structure
(ini->ib_dev) before dropping the mutex.

Connection establishment then continues across multiple function calls:
smc_find_proposal_devices() -> smc_connect_rdma() -> smc_conn_create()
using this un-refcounted pointer.

If the IB device is concurrently hot-unplugged, smc_ib_remove_dev() will
kfree() the device. Might the connection setup path then dereference the
freed memory?

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

  reply	other threads:[~2026-07-10  9:56 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-09  9:55 [PATCH rdma-next 00/13] RDMA: Make device names unique per net namespace Jiri Pirko
2026-07-09  9:55 ` [PATCH rdma-next 01/13] RDMA/core: Pass the net namespace to the device name lookups Jiri Pirko
2026-07-09  9:55 ` [PATCH rdma-next 02/13] RDMA/core: Handle device name conflicts when changing net namespace Jiri Pirko
2026-07-10  9:56   ` sashiko-bot
2026-07-09  9:55 ` [PATCH rdma-next 03/13] RDMA/core: Support renaming a device when changing its " Jiri Pirko
2026-07-10  9:56   ` sashiko-bot
2026-07-09  9:55 ` [PATCH rdma-next 04/13] RDMA/nldev: Report net namespace move errors through extack Jiri Pirko
2026-07-09  9:55 ` [PATCH rdma-next 05/13] RDMA/nldev: Allow setting the device name while changing net namespace Jiri Pirko
2026-07-09  9:55 ` [PATCH rdma-next 06/13] net/smc: Look up the pnetid ib device within the " Jiri Pirko
2026-07-10  9:56   ` sashiko-bot [this message]
2026-07-09  9:55 ` [PATCH rdma-next 07/13] RDMA/srp: Make the SRP sysfs class net namespace aware Jiri Pirko
2026-07-09  9:55 ` [PATCH rdma-next 08/13] RDMA/cgroup: Scope rdma cgroup device visibility to the net namespace Jiri Pirko
2026-07-09 13:04   ` Michal Koutný
2026-07-10  9:56   ` sashiko-bot
2026-07-09  9:55 ` [PATCH rdma-next 09/13] RDMA/cma: Document that CM configfs cannot be net namespace scoped Jiri Pirko
2026-07-09  9:55 ` [PATCH rdma-next 10/13] RDMA/core: Document the SELinux ibendport net namespace limitation Jiri Pirko
2026-07-09  9:55 ` [PATCH rdma-next 11/13] RDMA/core: Make device names unique per net namespace Jiri Pirko
2026-07-09  9:55 ` [PATCH rdma-next 12/13] RDMA/rxe: Implement disassociate_ucontext callback Jiri Pirko
2026-07-10  4:21   ` Zhu Yanjun
2026-07-10  9:56   ` sashiko-bot
2026-07-09  9:55 ` [PATCH rdma-next 13/13] RDMA/selftests: Add rxe_netns_names test Jiri Pirko
2026-07-10  4:24   ` Zhu Yanjun
2026-07-10  9:56   ` sashiko-bot
2026-07-10 23:51   ` yanjun.zhu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260710095628.C5FB51F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hannes@cmpxchg.org \
    --cc=hca@linux.ibm.com \
    --cc=jiri@resnulli.us \
    --cc=linux-s390@vger.kernel.org \
    --cc=mkoutny@suse.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.