From: sashiko-bot@kernel.org
To: "Haoxiang Li" <haoxiang_li2024@163.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH] scsi_sysfs: Fix runtime PM usage count leak on device add failure
Date: Mon, 22 Jun 2026 15:56:55 +0000 [thread overview]
Message-ID: <20260622155655.90BF11F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260622153721.1220711-1-haoxiang_li2024@163.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Dropping the runtime PM reference on the early device_add() error path queues an autosuspend timer that fires after the device is freed, causing a Use-After-Free.
--
commit 5af0e5ca0dba89028b4307b4434ee1726ec0169d
Author: Haoxiang Li <haoxiang_li2024@163.com>
scsi_sysfs: Fix runtime PM usage count leak on device add failure
This commit balances the scsi_autopm_get_device() call on the error paths of
scsi_sysfs_add_sdev() by releasing the runtime PM reference before returning.
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index dfc3559e7e04f..6b009e4f4b9e9 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -1427,7 +1427,7 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
> if (error) {
> sdev_printk(KERN_INFO, sdev,
> "failed to add device: %d\n", error);
> - return error;
> + goto out_autopm_put;
[Severity: High]
Could jumping to out_autopm_put here lead to a use-after-free when the first
device_add() fails?
If device_add(&sdev->sdev_gendev) fails early, for example in kobject_add()
or bus_add_device(), device_pm_remove() is not called internally. This leaves
runtime PM actively enabled on the device.
When scsi_autopm_put_device() is then called at the out_autopm_put label,
it drops the usage count to 0 while PM is still enabled. This can trigger
the scsi_runtime_idle() callback, which arms the background autosuspend
timer via pm_runtime_autosuspend().
If the caller subsequently frees the sdev struct without calling
pm_runtime_disable() to cancel the pending timers, could the autosuspend timer
fire and access the freed sdev memory?
> }
>
> device_enable_async_suspend(&sdev->sdev_dev);
[ ... ]
> @@ -1452,6 +1452,7 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
> }
> }
>
> +out_autopm_put:
> scsi_autopm_put_device(sdev);
> return error;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260622153721.1220711-1-haoxiang_li2024@163.com?part=1
prev parent reply other threads:[~2026-06-22 15:56 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-22 15:37 [PATCH] scsi_sysfs: Fix runtime PM usage count leak on device add failure Haoxiang Li
2026-06-22 15:56 ` sashiko-bot [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=20260622155655.90BF11F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=haoxiang_li2024@163.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox