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
next prev parent 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