[PATCH] scsi_sysfs: Fix runtime PM usage count leak on device add failure

[PATCH] scsi_sysfs: Fix runtime PM usage count leak on device add failure

[Haoxiang Li]

Balance the scsi_autopm_get_device() call on the error paths of
scsi_sysfs_add_sdev() by releasing the runtime PM reference before
returning.

Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
---
 drivers/scsi/scsi_sysfs.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index dfc3559e7e04..6b009e4f4b9e 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;
 	}
 
 	device_enable_async_suspend(&sdev->sdev_dev);
@@ -1436,7 +1436,7 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
 		sdev_printk(KERN_INFO, sdev,
 				"failed to add class device: %d\n", error);
 		device_del(&sdev->sdev_gendev);
-		return error;
+		goto out_autopm_put;
 	}
 	transport_add_device(&sdev->sdev_gendev);
 	sdev->is_visible = 1;
@@ -1452,6 +1452,7 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
 		}
 	}
 
+out_autopm_put:
 	scsi_autopm_put_device(sdev);
 	return error;
 }
-- 
2.25.1

Re: [PATCH] scsi_sysfs: Fix runtime PM usage count leak on device add failure

[sashiko-bot]

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