From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jiale Yao <yaojiale02@163.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>,
Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
Stephen Hemminger <stephen@networkplumber.org>,
"K. Y. Srinivasan" <kys@microsoft.com>,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] hv/vmbus: copy dynamic IDs before dropping the lock
Date: Mon, 19 Oct 2026 15:35:38 +0200 [thread overview]
Message-ID: <2026101936-livable-plug-8bc9@gregkh> (raw)
In-Reply-To: <20261019085544.1834700-1-yaojiale02@163.com>
On Mon, Oct 19, 2026 at 04:55:44PM +0800, Jiale Yao wrote:
> remove_id_store() can free a matching dynamic ID while VMBus is
> preparing to invoke a driver probe.
And how can that be triggered?
> Copy the ID while holding the dynamic ID lock so probe never receives
> a pointer into a freed list entry.
Why is this driver allowed to handle dynamic ids at all? Is it really
required? That will taint the kernel so no real workflow requires it,
right?
> Fixes: fc76936d3ea5 ("vmbus: add support for dynamic device id's")
No cc: stable?
> Signed-off-by: Jiale Yao <yaojiale02@163.com>
> ---
> drivers/hv/vmbus_drv.c | 25 +++++++++++++++----------
> 1 file changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 4692687cdbf3..96ad0dfaa50b 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -661,21 +661,22 @@ 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)
> {
> - const struct hv_vmbus_device_id *id = NULL;
> 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;
> + *id_copy = dynid->id;
Shouldn't this be a memcpy() as that's what you are really doing?
> + spin_unlock(&drv->dynids.lock);
guard() usage instead?
> + return id_copy;
> }
> }
> spin_unlock(&drv->dynids.lock);
>
> - return id;
> + return NULL;
> }
>
> static const struct hv_vmbus_device_id vmbus_device_null;
> @@ -685,7 +686,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 +699,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);
>
> @@ -773,6 +775,7 @@ static ssize_t new_id_store(struct device_driver *driver, const char *buf,
> size_t count)
> {
> struct hv_driver *drv = drv_to_hv_drv(driver);
> + struct hv_vmbus_device_id id_copy;
On the stack?
Ok, I guess this would work, but it feels clunky, why doesn't all other
busses have to do this too?
thanks,
greg k-h
prev parent reply other threads:[~2026-10-19 13:35 UTC|newest]
Thread overview: 3+ 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
2026-10-19 13:35 ` Greg Kroah-Hartman [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=2026101936-livable-plug-8bc9@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@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 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.