Linux-HyperV List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jiale Yao" <yaojiale02@163.com>, linux-hyperv@vger.kernel.org
Subject: Re: [PATCH] hv/vmbus: copy dynamic IDs before dropping the lock
Date: Mon, 19 Oct 2026 09:10:02 +0000	[thread overview]
Message-ID: <sashiko-outbox-176875@kernel.org> (raw)
In-Reply-To: <20261019085544.1834700-1-yaojiale02@163.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] hv/vmbus: NULL dev_id passed to drv->probe() in vmbus_probe() on dynid race
--

commit 3bc8de7f762094d04ea5ef5ada2811cd26424021
Author: Jiale Yao <yaojiale02@163.com>

hv/vmbus: copy dynamic IDs before dropping the lock

This commit copies matching dynamic device IDs into a caller-provided stack
variable while holding drv->dynids.lock so that driver probe callbacks do not
receive a pointer to a dynamic ID entry that was concurrently freed by
remove_id_store().

> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 4692687cdbf3b..96ad0dfaa50ba 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c

[ ... ]

> @@ -860,9 +864,10 @@ static int vmbus_probe(struct device *child_device)
>  	struct hv_driver *drv =
>  			drv_to_hv_drv(child_device->driver);
>  	struct hv_device *dev = device_to_hv_device(child_device);
> +	struct hv_vmbus_device_id dev_id_copy;
>  	const struct hv_vmbus_device_id *dev_id;
>  
> -	dev_id = hv_vmbus_get_id(drv, dev);
> +	dev_id = hv_vmbus_get_id(drv, dev, &dev_id_copy);
>  	if (drv->probe) {
>  		ret = drv->probe(dev, dev_id);
>  		if (ret != 0)

[Severity: High]
What happens if remove_id_store() removes the matching dynamic ID after
vmbus_match() succeeds, but before vmbus_probe() calls hv_vmbus_get_id()?

Since vmbus_match() and vmbus_probe() acquire and release drv->dynids.lock
separately via hv_vmbus_get_id() -> hv_vmbus_dynid_match(), a concurrent
remove_id_store() can delete the matching entry in between:

drivers/hv/vmbus_drv.c:remove_id_store() {
	...
	spin_lock(&drv->dynids.lock);
	list_for_each_entry_safe(dynid, n, &drv->dynids.list, node) {
		struct hv_vmbus_device_id *id = &dynid->id;

		if (guid_equal(&id->guid, &guid)) {
			list_del(&dynid->node);
			kfree(dynid);
			retval = count;
			break;
		}
	}
	spin_unlock(&drv->dynids.lock);
	...
}

When that happens (or if driver_override is cleared between vmbus_match()
and vmbus_probe()), hv_vmbus_get_id() in vmbus_probe() returns NULL, and
vmbus_probe() passes dev_id = NULL to drv->probe(dev, dev_id).

Drivers such as storvsc and hv_util unconditionally dereference dev_id in
their probe callbacks:

drivers/scsi/storvsc_drv.c:storvsc_probe() {
	...
	bool dev_is_ide = dev_id->driver_data == IDE_GUID;
	bool is_fc = dev_id->driver_data == SFC_GUID;
	...
}

drivers/hv/hv_util.c:util_probe() {
	struct hv_util_service *srv =
		(struct hv_util_service *)dev_id->driver_data;
	...
}

And for drivers that do not dereference dev_id (such as uio_hv_generic),
probe will still succeed and bind the device even though the dynamic ID was
already removed.

Should vmbus_probe() check if (!dev_id && !is_hvsock_channel(dev->channel))
and return -ENODEV before calling drv->probe(), similar to how
__pci_device_probe() and usb_probe_interface() handle a removed dynamic ID?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261019085544.1834700-1-yaojiale02@163.com?part=1

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

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-19  8:55 [PATCH] hv/vmbus: copy dynamic IDs before dropping the lock Jiale Yao
2026-10-19  9:10 ` sashiko-bot [this message]
2026-10-19 13:35 ` Greg Kroah-Hartman
2026-10-20 23:30 ` Kameron Carr

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=sashiko-outbox-176875@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=yaojiale02@163.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox