Re: [PATCH V3 01/14] i3c: master: Fix recursive locking during device registration

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

Pre-existing issues:
- [High] Use-After-Free of `i3cdev->desc` during unlocked driver core callb=
acks (e.g., `i3c_device_match`) racing with Dynamic Address Assignment (DAA=
).
--

--- Patch [1]: [PATCH V3 01/14] i3c: master: Fix recursive locking during d=
evice registration ---
commit b974ff3a9bff008bbc487a2d9b2d24a4539bff06
Author: Adrian Hunter <[email protected]>

i3c: master: Fix recursive locking during device registration

This commit fixes recursive locking during i3c device registration by
separating device creation from registration. It populates the device
under the maintenance lock, collects unregistered devices into a list,
and calls device_register() only after releasing the lock.

> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c

[ ... ]

> @@ -2104,25 +2113,37 @@ i3c_master_register_new_i3c_devs(struct i3c_maste=
r_controller *master)

[ ... ]

> +	i3c_bus_maintenance_unlock(&master->bus);
> +
> +	list_for_each_entry_safe(i3cdev, tmp, &i3c_unreg_devs, node) {
> +		ret =3D device_register(&i3cdev->dev);

[Severity: High]
This is a pre-existing issue, but does dropping the maintenance lock here
expose driver core callbacks to a use-after-free of i3cdev->desc?

When device_register() runs without the maintenance lock, synchronous driver
core callbacks like i3c_device_match() can locklessly dereference
i3cdev->desc:

drivers/i3c/master.c:i3c_device_match() {
    ...
    if (i3cdev->desc && i3cdev->desc->boardinfo)
        static_addr_method =3D i3cdev->desc->boardinfo->static_addr_method;
    ...
}

Concurrently, a hot-join event triggering dynamic address assignment (DAA)
could take the maintenance lock and free the old descriptor if it identifies
the device as a duplicate:

drivers/i3c/master.c:__i3c_master_add_i3c_dev_locked() {
    ...
    i3c_master_detach_i3c_dev(olddev);
    i3c_master_free_i3c_dev(olddev);
    ...
}

Could this sequence cause a use-after-free when the unlocked callback
races with DAA freeing the duplicate descriptor?

> +		if (ret)
> +			dev_err(&master->dev, "Failed to add I3C device (err =3D %d)\n", ret);
> +		else
> +			list_del_init(&i3cdev->node);
> +	}

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260804133810.1849=
[email protected]?part=3D1