From: sashiko-bot@kernel.org
To: "Ruoyu Wang" <ruoyuw560@gmail.com>
Cc: Frank.Li@kernel.org,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
linux-i3c@lists.infradead.org
Subject: Re: [PATCH] i3c: master: Release I2C boardinfo node reference
Date: Fri, 14 Aug 2026 13:58:40 +0000 [thread overview]
Message-ID: <20260814135841.2772F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260814134027.1386818-1-ruoyuw560@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Use-After-Free and Double-Free on I3C device registration failure.
--
--- Patch [1]: [PATCH] i3c: master: Release I2C boardinfo node reference ---
commit fb94e3e139711c2723cb1a74b85c8a9c79efcfd3
Author: Ruoyu Wang <ruoyuw560@gmail.com>
i3c: master: Release I2C boardinfo node reference
The commit registers the board-info node reference as a managed resource
of the I3C master. This ensures the reference is properly retained for the
full lifetime of the board-info and released on both registration failure
and normal master teardown, preventing memory leaks.
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index f1be38a640ca1..8063e2642cbda 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c
[ ... ]
[Severity: High]
This is a pre-existing issue, but while reviewing this file, I noticed a
potential use-after-free and double-free regression when handling I3C
device registration failures.
If device_register() fails in i3c_master_register_new_i3c_devs(), put_device()
is called to free desc->dev:
drivers/i3c/master.c:i3c_master_register_new_i3c_devs() {
...
ret = device_register(&desc->dev->dev);
if (ret) {
dev_err(&master->dev,
"Failed to add I3C device (err = %d)\n", ret);
put_device(&desc->dev->dev);
}
...
}
However, desc->dev is not set to NULL after being freed, leaving a dangling
pointer on the master's bus list.
If the master is later unregistered, i3c_master_unregister_i3c_devs() iterates
over the bus list and accesses this dangling pointer:
drivers/i3c/master.c:i3c_master_unregister_i3c_devs() {
...
i3c_bus_for_each_i3cdev(&master->bus, i3cdev) {
if (!i3cdev->dev)
continue;
i3cdev->dev->desc = NULL;
if (device_is_registered(&i3cdev->dev->dev))
device_unregister(&i3cdev->dev->dev);
else
put_device(&i3cdev->dev->dev);
i3cdev->dev = NULL;
}
...
}
Could this sequence lead to writing to freed memory when setting
i3cdev->dev->desc to NULL, followed by a double-free when put_device() is
called again?
Would it be safer to clear the desc->dev pointer in the error path of
i3c_master_register_new_i3c_devs() after the initial put_device() call?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260814134027.1386818-1-ruoyuw560@gmail.com?part=1
--
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
prev parent reply other threads:[~2026-08-14 13:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 13:40 [PATCH] i3c: master: Release I2C boardinfo node reference Ruoyu Wang
2026-08-14 13:40 ` Ruoyu Wang
2026-08-14 13:58 ` sashiko-bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260814135841.2772F1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=alexandre.belloni@bootlin.com \
--cc=linux-i3c@lists.infradead.org \
--cc=ruoyuw560@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.