Re: [PATCH] drm/xe/i2c: Fix use-after-free on driver unload

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/xe/i2c: UAF on client devices when i2c_designware is unbound
--

commit acaaddc70630047a3af20f747eb4eed375a715a1
Author: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>

drm/xe/i2c: Fix use-after-free on driver unload

This patch fixes a use-after-free during driver unload by replacing the managed
software node with a static struct software_node. It also modifies
xe_i2c_notifier() to match against the parent device instead of using i2c->dev,
removing a dependency in the two-step platform device creation sequence.

> diff --git a/drivers/gpu/drm/xe/xe_i2c.c b/drivers/gpu/drm/xe/xe_i2c.c
> index f4f3819882897..f0566129b7e70 100644
> --- a/drivers/gpu/drm/xe/xe_i2c.c
> +++ b/drivers/gpu/drm/xe/xe_i2c.c
[ ... ]
> @@ -98,7 +102,7 @@ static int xe_i2c_notifier(struct notifier_block *nb, unsigned long action, void
>  	struct device *dev = data;
>  
>  	if (action == BUS_NOTIFY_ADD_DEVICE &&
> -	    adapter && dev->parent == &i2c->pdev->dev) {
> +	    adapter && dev->parent && dev->parent->parent == i2c->drm_dev) {
>  		i2c->adapter = adapter;
>  		schedule_work(&i2c->work);
>  		return NOTIFY_OK;
>  	}
>  
>  	return NOTIFY_DONE;
>  }

[Severity: High]
Does this missing BUS_NOTIFY_DEL_DEVICE handler leave dangling pointers if the
i2c-designware driver is manually unbound? 

If the adapter is unbound (e.g. via sysfs), the I2C core will unregister and
free all connected I2C client devices. Because this notifier doesn't handle
device removal, i2c->adapter and i2c->client[i] are never cleared and become
dangling pointers.

Later during module teardown, the xe_i2c_remove() devm action executes:

drivers/gpu/drm/xe/xe_i2c.c:xe_i2c_remove() {
	...
	for (i = 0; i < XE_I2C_MAX_CLIENTS; i++) {
		i2c_unregister_device(i2c->client[i]);
		i2c->client[i] = NULL;
	}
	...
}

Will this explicitly call i2c_unregister_device() on already freed client
pointers, causing a use-after-free crash? Additionally, if the unbind occurs
before xe_i2c_client_work() executes, could the workqueue dereference the freed
i2c->adapter pointer?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261009164241.923756-2-balasubramani.vivekanandan@intel.com?part=1