All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "David Jeffery" <djeffery@redhat.com>
Cc: linux-scsi@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH 5/9] driver core: do not always lock parent in shutdown
Date: Wed, 02 Sep 2026 17:25:23 +0000	[thread overview]
Message-ID: <20260902172523.C99101F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260902170734.95504-6-djeffery@redhat.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Incorrect condition ordering leads to a potential Use-After-Free of `dev->bus` during device shutdown.
--

commit b894dd7ffd5113988601f8e495c49a29524ecb74
Author: David Jeffery <djeffery@redhat.com>

driver core: do not always lock parent in shutdown

This commit avoids unconditionally locking a parent device during device
shutdown. It introduces __shutdown_one_device and updates
shutdown_one_device to only acquire the parent lock when needed to prevent
races with probe or release operations.

> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 7fe3fa6870a72..05285fae143d3 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
[ ... ]
> @@ -4928,13 +4926,33 @@ static void shutdown_one_device(struct device *dev, struct device *parent)
>  			dev_info(dev, "shutdown\n");
>  		dev->driver->shutdown(dev);
>  	}
> +}
>  
> -	device_unlock(dev);
> -	if (parent)
> +static void shutdown_one_device(struct device *dev)
> +{
> +	struct device *parent;
> +
> +	device_lock(dev);
> +
> +	/* use parent lock if needed to avoid race with probe/release */
> +	if (dev->bus && dev->bus->need_parent_lock && dev->p && !dev->p->dead &&
[Severity: High]
Could this condition ordering lead to a use-after-free during device shutdown?

If a module is unloaded concurrently with system shutdown, device_del() sets
dev->p->dead to true and removes the device from the bus.

Since device_shutdown() already incremented the device's refcount, the
device structure is preserved. However, when the module finishes unloading, it
unregisters the bus and frees the bus_type structure.

Because of left-to-right evaluation in this if statement,
dev->bus->need_parent_lock is accessed before checking !dev->p->dead.

Would checking dev->p && !dev->p->dead before accessing bus properties
prevent reading from the potentially unmapped bus structure?

> +	    (parent = get_device(dev->parent))) {
> +		/* the parent lock needs to be acquired first, so re-lock */
> +		device_unlock(dev);
> +
> +		device_lock(parent);
> +		device_lock(dev);
> +
> +		__shutdown_one_device(dev);
> +		device_unlock(dev);
>  		device_unlock(parent);
> +		put_device(parent);
> +	} else {
> +		__shutdown_one_device(dev);
> +		device_unlock(dev);
> +	}
>  
>  	put_device(dev);
> -	put_device(parent);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902170734.95504-1-djeffery@redhat.com?part=5

  reply	other threads:[~2026-09-02 17:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02 17:07 [PATCH v21 0/9] shut down devices asynchronously David Jeffery
2026-09-02 17:07 ` [PATCH 1/9] driver core: rely on put_device to free dev->p David Jeffery
2026-09-02 17:16   ` sashiko-bot
2026-09-02 17:07 ` [PATCH 2/9] driver core: prevent device_add() during system shutdown David Jeffery
2026-09-02 17:15   ` sashiko-bot
2026-09-02 17:07 ` [PATCH 3/9] driver core: warn should device_move try to move a need_parent_lock device David Jeffery
2026-09-02 17:22   ` sashiko-bot
2026-09-02 17:07 ` [PATCH 4/9] driver core: separate function to shutdown one device David Jeffery
2026-09-02 17:13   ` sashiko-bot
2026-09-02 17:07 ` [PATCH 5/9] driver core: do not always lock parent in shutdown David Jeffery
2026-09-02 17:25   ` sashiko-bot [this message]
2026-09-02 17:07 ` [PATCH 6/9] driver core: async device shutdown infrastructure David Jeffery
2026-09-02 17:17   ` sashiko-bot
2026-09-02 17:07 ` [PATCH 7/9] PCI: Link a virtual function to its physical function David Jeffery
2026-09-02 17:17   ` sashiko-bot
2026-09-03 22:12   ` Bjorn Helgaas
2026-09-02 17:07 ` [PATCH 8/9] PCI: Enable async shutdown support David Jeffery
2026-09-02 17:24   ` sashiko-bot
2026-09-02 17:07 ` [PATCH 9/9] scsi: " David Jeffery
2026-09-02 17:26   ` sashiko-bot
  -- strict thread matches above, loose matches on Subject: below --
2026-08-21 14:24 [PATCH v20 0/9] shut down devices asynchronously David Jeffery
2026-08-21 14:24 ` [PATCH 5/9] driver core: do not always lock parent in shutdown David Jeffery
2026-08-21 14:33   ` sashiko-bot

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=20260902172523.C99101F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=djeffery@redhat.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.