[PATCH V2 5/8] i3c: master: Reject IBI requests from non-IBI-capable devices

sashiko-bot at kernel.org sashiko-bot at kernel.org
Tue Jul 28 10:06:05 PDT 2026


Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Leaked workqueue in `i3c_dev_request_ibi_locked()` when `master->ops->request_ibi()` fails.
--

--- Patch [5]: [PATCH V2 5/8] i3c: master: Reject IBI requests from non-IBI-capable devices ---
commit d69e542b87c33e0789e410767b2ee354fe000c28
Author: Adrian Hunter <adrian.hunter at intel.com>
i3c: master: Reject IBI requests from non-IBI-capable devices

This commit adds a check in i3c_device_request_ibi() to ensure a device
reports IBI support before attempting to set up IBI handling. If the device
does not advertise I3C_BCR_IBI_REQ_CAP, it now fails with -EOPNOTSUPP.

> diff --git a/drivers/i3c/device.c b/drivers/i3c/device.c
> index 101eaa77de686..307ca6dc04ca0 100644
> --- a/drivers/i3c/device.c
> +++ b/drivers/i3c/device.c
> @@ -205,12 +205,14 @@ int i3c_device_request_ibi(struct i3c_device *dev,
>  		return ret;
>  
>  	i3c_bus_normaluse_lock(dev->bus);
> -	if (dev->desc) {
> +	if (!dev->desc) {
> +		ret = -ENOENT;
> +	} else if (!(dev->desc->info.bcr & I3C_BCR_IBI_REQ_CAP)) {
> +		ret = -EOPNOTSUPP;
> +	} else {
>  		mutex_lock(&dev->desc->ibi_lock);
>  		ret = i3c_dev_request_ibi_locked(dev->desc, req);

[Severity: High]
This is a pre-existing issue, but does i3c_dev_request_ibi_locked() leak the
allocated workqueue if the master's request_ibi callback fails?

Looking at i3c_dev_request_ibi_locked() in drivers/i3c/master.c:

	ibi->wq = alloc_ordered_workqueue(dev_name(i3cdev_to_dev(dev->dev)),
					  WQ_MEM_RECLAIM);
	if (!ibi->wq) {
		kfree(ibi);
		return -ENOMEM;
	}
	...
	ret = master->ops->request_ibi(dev, req);
	if (ret) {
		kfree(ibi);
		dev->ibi = NULL;
	}

If master->ops->request_ibi() returns an error, the error path frees ibi
but doesn't call destroy_workqueue(ibi->wq).

If a device probe repeatedly fails at this step, could this result in a
workqueue and memory leak?

>  		mutex_unlock(&dev->desc->ibi_lock);
> -	} else {
> -		ret = -ENOENT;
>  	}
>  	i3c_bus_normaluse_unlock(dev->bus);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260728155308.142713-1-adrian.hunter@intel.com?part=5



More information about the linux-i3c mailing list