Re: [PATCH v2] driver core: bind a device with a preset driver even without autoprobe

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] driver core: lockless TOCTOU race in device_initial_probe() bypasses autoprobe=0
--

commit e63fcf260c7ac274ae164a5fb03accba2fcada52
Author: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>

driver core: bind a device with a preset driver even without autoprobe

When drivers_autoprobe is disabled, device_initial_probe() skipped
calling __device_attach(). This commit ensures that devices with a
preset driver still undergo binding even if autoprobe is disabled,
preventing a NULL pointer dereference in klist_remove() on unbind.

Closes: https://syzkaller.appspot.com/bug?extid=863936f50214e843ae0c

> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index f6525a7ee8c54..137bf1dea3333 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -1149,7 +1149,8 @@ void device_initial_probe(struct device *dev)
>  	if (!sp)
>  		return;
>  
> -	if (sp->drivers_autoprobe)
> +	/* a device with a preset driver must still be bound */
> +	if (sp->drivers_autoprobe || dev->driver)
>  		__device_attach(dev, true);

[Severity: Medium]
Does this lockless check of dev->driver introduce a TOCTOU race that
bypasses the autoprobe disabled state?

If sp->drivers_autoprobe is disabled, this code relies on dev->driver
being non-NULL to trigger __device_attach(). However, if dev->driver is
cleared concurrently (for instance, via a hardware disconnect or a sysfs
unbind), __device_attach() will see dev->driver as NULL under the
device lock.

When __device_attach() sees dev->driver as NULL, it takes the else branch
and executes the fallback bus_for_each_drv() probe:

drivers/base/dd.c:__device_attach() {
    ...
	} else if (dev->driver) {
    ...
	} else {
		struct device_attach_data data = {
			.dev = dev,
			.check_async = allow_async,
			.want_async = false,
		};
    ...
		ret = bus_for_each_drv(dev->bus, NULL, &data,
					__device_attach_driver);
    ...
}

Will this cause an unintended auto-probe across all drivers on the bus,
violating the autoprobe=0 configuration?

>  
>  	subsys_put(sp);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261008144859.25548-1-ngocthang2710.1999@gmail.com?part=1