From: Michael Kelley <mhklinux@outlook.com>
To: Jiale Yao <yaojiale02@163.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Stephen Hemminger <stephen@networkplumber.org>,
"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "stable@vger.kernel.org" <stable@vger.kernel.org>,
Kameron Carr <kameroncarr@linux.microsoft.com>
Subject: RE: [PATCH v3 2/2] Drivers: hv: vmbus: copy dynamic IDs before dropping the lock
Date: Tue, 27 Oct 2026 16:53:00 +0000 [thread overview]
Message-ID: <MN2PR02MB68638470758B9B7CCAC3377AD4602@MN2PR02MB6863.namprd02.prod.outlook.com> (raw)
In-Reply-To: <20261027065642.2280297-3-yaojiale02@163.com>
From: Jiale Yao <yaojiale02@163.com> Sent: Monday, October 26, 2026 11:57 PM
>
> Dynamic IDs are freed by remove_id_store() while holding dynids.lock, so a
> pointer into a dynamic ID entry is valid only while that lock is held.
> hv_vmbus_dynid_match() currently returns such a pointer after unlocking. A
> concurrent remove_id write can therefore free the entry before a driver
> probe dereferences it.
>
> Copy a matching dynamic ID under the lock and pass the caller-owned copy to
> the probe callback. This follows the lifetime handling added for PCI by
> commit 3ffc4c9690c3 ("PCI: Fix UAF when probe runs concurrent to dyn ID
> removal") and for USB by commit ef8154d8b52d ("usb: fix UAF when probe runs
> concurrent to dyn ID removal"). Document that the ID is valid only for the
> duration of probe.
>
> Because matching and probing perform separate lookups, removal can also
> happen between them. Reject the probe if the second lookup no longer finds
> an ID instead of passing NULL to drivers which dereference it. Keep the
> hvsock exception because it does not use an ID table or inspect the ID.
I had a little trouble mapping this paragraph to the code, but eventually
figured it out. For more clarity, I would have done this paragraph something like:
Current code in vmbus_probe() assumes that hv_vmbus_get_id() will
always succeed because vmbus_probe() isn't called unless there's an
ID match. But matching and probing perform separate lookups, so
removal can happen between them. Check the result of probe lookup,
and reject the probe if it fails instead of allowing drivers to dereference
NULL. But like in vmbus_match(), make an exception for hvsock because
it does not use an ID table or inspect the ID.
Don't respin the patch set just for this change. Maybe Wei Liu can
tweak it when he applies the patch set.
>
> This issue was found by static analysis of the dynamic ID lifetime.
>
> Fixes: fc76936d3ea5 ("vmbus: add support for dynamic device id's")
> Cc: stable@vger.kernel.org
> Tested-by: Kameron Carr <kameroncarr@linux.microsoft.com>
> Reviewed-by: Kameron Carr <kameroncarr@linux.microsoft.com>
> Signed-off-by: Jiale Yao <yaojiale02@163.com>
> ---
> drivers/hv/vmbus_drv.c | 34 ++++++++++++++++++++--------------
> include/linux/hyperv.h | 1 +
> 2 files changed, 21 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 1037117e2d81..1cacbc71266f 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -661,21 +661,21 @@ hv_vmbus_dev_match(const struct hv_vmbus_device_id *id, const guid_t *guid)
> }
>
> static const struct hv_vmbus_device_id *
> -hv_vmbus_dynid_match(struct hv_driver *drv, const guid_t *guid)
> +hv_vmbus_dynid_match(struct hv_driver *drv, const guid_t *guid,
> + struct hv_vmbus_device_id *id_copy)
This change to the function signature, and similarly for hv_vmbus_get_id(),
produces a rather unusual result. Upon success, the function returns the
new 2nd argument. It took me a little while to figure that out, just
because it's unexpected. A more normal function signature would be
to return a result code to indicate success or failure, with the new 2nd
argument containing the actual ID value that is wanted upon success.
I realize you are following the pattern established by PCI and USB
commits mentioned in your commit message. And there's real
value in consistency. So this is just commentary and not a request
for a code change. Leave it as you have written it for consistency,
but it is a bit weird. :-)
All that said,
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
> {
> - const struct hv_vmbus_device_id *id = NULL;
> - struct vmbus_dynid *dynid;
> + scoped_guard(spinlock, &drv->dynids.lock) {
> + struct vmbus_dynid *dynid;
>
> - spin_lock(&drv->dynids.lock);
> - list_for_each_entry(dynid, &drv->dynids.list, node) {
> - if (guid_equal(&dynid->id.guid, guid)) {
> - id = &dynid->id;
> - break;
> + list_for_each_entry(dynid, &drv->dynids.list, node) {
> + if (guid_equal(&dynid->id.guid, guid)) {
> + memcpy(id_copy, &dynid->id, sizeof(*id_copy));
> + return id_copy;
> + }
> }
> }
> - spin_unlock(&drv->dynids.lock);
>
> - return id;
> + return NULL;
> }
>
> static const struct hv_vmbus_device_id vmbus_device_null;
> @@ -685,7 +685,8 @@ static const struct hv_vmbus_device_id vmbus_device_null;
> * If there is no match, return NULL.
> */
> static const struct hv_vmbus_device_id *hv_vmbus_get_id(const struct hv_driver *drv,
> - struct hv_device *dev)
> + struct hv_device *dev,
> + struct hv_vmbus_device_id *id_copy)
> {
> const guid_t *guid = &dev->dev_type;
> const struct hv_vmbus_device_id *id;
> @@ -697,7 +698,7 @@ static const struct hv_vmbus_device_id *hv_vmbus_get_id(const struct hv_driver *
> return NULL;
>
> /* Look at the dynamic ids first, before the static ones */
> - id = hv_vmbus_dynid_match((struct hv_driver *)drv, guid);
> + id = hv_vmbus_dynid_match((struct hv_driver *)drv, guid, id_copy);
> if (!id)
> id = hv_vmbus_dev_match(drv->id_table, guid);
>
> @@ -843,13 +844,14 @@ ATTRIBUTE_GROUPS(vmbus_drv);
> static int vmbus_match(struct device *device, const struct device_driver *driver)
> {
> const struct hv_driver *drv = drv_to_hv_drv(driver);
> + struct hv_vmbus_device_id id_copy;
> struct hv_device *hv_dev = device_to_hv_device(device);
>
> /* The hv_sock driver handles all hv_sock offers. */
> if (is_hvsock_channel(hv_dev->channel))
> return drv->hvsock;
>
> - if (hv_vmbus_get_id(drv, hv_dev))
> + if (hv_vmbus_get_id(drv, hv_dev, &id_copy))
> return 1;
>
> return 0;
> @@ -864,9 +866,13 @@ 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 (!dev_id && !is_hvsock_channel(dev->channel))
> + return -ENODEV;
> +
> if (drv->probe) {
> ret = drv->probe(dev, dev_id);
> if (ret != 0)
> diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
> index e61f9a4cb7c3..1d5862725f24 100644
> --- a/include/linux/hyperv.h
> +++ b/include/linux/hyperv.h
> @@ -1264,6 +1264,7 @@ struct hv_driver {
> struct list_head list;
> } dynids;
>
> + /* The device ID pointer is only valid during the probe callback. */
> int (*probe)(struct hv_device *, const struct hv_vmbus_device_id *);
> void (*remove)(struct hv_device *dev);
> void (*shutdown)(struct hv_device *);
> --
> 2.34.1
>
prev parent reply other threads:[~2026-10-27 16:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-27 6:56 [PATCH v3 0/2] Drivers: hv: vmbus: fix dynamic ID races Jiale Yao
2026-10-27 6:56 ` [PATCH v3 1/2] Drivers: hv: vmbus: prevent duplicate dynamic IDs Jiale Yao
2026-10-27 17:09 ` Michael Kelley
2026-10-27 6:56 ` [PATCH v3 2/2] Drivers: hv: vmbus: copy dynamic IDs before dropping the lock Jiale Yao
2026-10-27 16:53 ` Michael Kelley [this message]
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=MN2PR02MB68638470758B9B7CCAC3377AD4602@MN2PR02MB6863.namprd02.prod.outlook.com \
--to=mhklinux@outlook.com \
--cc=decui@microsoft.com \
--cc=gregkh@linuxfoundation.org \
--cc=haiyangz@microsoft.com \
--cc=kameroncarr@linux.microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=stephen@networkplumber.org \
--cc=wei.liu@kernel.org \
--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
all inboxes | Powered by JetHome®