Re: [PATCH] i2c: imx-lpi2c: avoid accessing target registers on master-only controllers

[email protected] Mon, 03 Aug 2026 03:35:38 +0000
Newsgroups dev.linux.lists.imx
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:

Pre-existing issues:
- [High] Missing rollback in `lpi2c_imx_register_target()` when `pm_runtime=
_resume_and_get()` fails, leaving a dangling pointer in `lpi2c_imx->target`.
--

--- Patch [1]: [PATCH] i2c: imx-lpi2c: avoid accessing target registers on =
master-only controllers ---
commit c2a5eb969b33b95968f240043a2bfa7ba6e85caf
Author: Carlos Song <[email protected]>

i2c: imx-lpi2c: avoid accessing target registers on master-only controllers

This commit reads the VERID register during probe to check for target mode
support. It prevents accessing target registers on master-only controllers
and rejects target registration requests if unsupported.

> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-=
imx-lpi2c.c
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
[ ... ]
> @@ -1330,6 +1335,10 @@ static int lpi2c_imx_register_target(struct i2c_cl=
ient *client)
>  	struct lpi2c_imx_struct *lpi2c_imx =3D i2c_get_adapdata(client->adapter=
);
>  	int ret;
> =20
> +	/* Reject target-mode registration on controllers that don't support it=
. */
> +	if (!lpi2c_imx->target_supported)
> +		return -EOPNOTSUPP;
> +
>  	if (lpi2c_imx->target)
>  		return -EBUSY;
> =20
>  	lpi2c_imx->target =3D client;
> =20
>  	ret =3D pm_runtime_resume_and_get(lpi2c_imx->adapter.dev.parent);
>  	if (ret < 0) {
>  		dev_err(&lpi2c_imx->adapter.dev, "failed to resume i2c controller");
>  		return ret;
>  	}

[Severity: High]
This is a pre-existing issue, but does this error path leave a dangling
pointer in the controller data?

If pm_runtime_resume_and_get() fails in lpi2c_imx_register_target(), the
function returns without clearing lpi2c_imx->target. Because the registrati=
on
failed, the target driver probe will fail and the i2c_client memory can be
freed (e.g., if dynamically removed or unbound).

Later, if the system is suspended and resumed, lpi2c_resume_noirq() will see
that lpi2c_imx->target is non-NULL and unconditionally dereference it:

drivers/i2c/busses/i2c-imx-lpi2c.c:lpi2c_resume_noirq() {
    ...
    if (lpi2c_imx->target)
        lpi2c_imx_target_init(lpi2c_imx);
    ...
}

Should lpi2c_imx->target be set back to NULL in this error path to avoid a
potential use-after-free crash?

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