From: sashiko-bot@kernel.org
To: "Akhil R" <akhilrajeev@nvidia.com>
Cc: Frank.Li@kernel.org,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
linux-i3c@lists.infradead.org
Subject: Re: [PATCH 1/5] i3c: master: Release the fwnode of i2c boardinfo
Date: Tue, 04 Aug 2026 10:33:05 +0000 [thread overview]
Message-ID: <20260804103306.A89B81F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260804101301.2975911-2-akhilrajeev@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The patch fixes a fwnode reference leak in `i3c_master_add_i2c_boardinfo()` but completely misses the identical leak in `i3c_master_add_i3c_boardinfo()`. Furthermore, there is a structural lifecycle flaw: `i3c_master_register_new_i3c_devs()` assigns the boardinfo's fwnode to the new I3C device without taking a reference, and `i3c_device_release()` unconditionally drops it. This means if one merely blindly copies the devm fix to `i3c_master_add_i3c_boardinfo()`, it would trigger a double-put UAF for instantiated devices. To fix the subsystem fully, both the devm action must be added and a `fwnode_handle_get()` must be taken in `i3c_master_register_new_i3c_devs()`.
--
--- Patch [1]: [PATCH 1/5] i3c: master: Release the fwnode of i2c boardinfo ---
commit 9b7e7e5dd15b80d230fc0e52c4d7b8ef9dea16c9
Author: Akhil R <akhilrajeev@nvidia.com>
i3c: master: Release the fwnode of i2c boardinfo
This commit fixes a fwnode reference leak in i3c_master_add_i2c_boardinfo().
It adds a devm action to automatically drop the firmware node reference taken
for every I2C child device when the controller device is unbound.
Closes: https://lore.kernel.org/all/97465893-3650-4f37-98b7-1db76fc6fd03@intel.com/
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index f485b98805cf6..08dc10f172aab 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c
> @@ -2913,7 +2918,8 @@ i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
> list_add_tail(&boardinfo->node, &master->boardinfo.i2c);
> fwnode_handle_get(fwnode);
>
> - return 0;
> + return devm_add_action_or_reset(dev, i3c_master_put_boardinfo_fwnode,
> + fwnode);
> }
[Severity: High]
This is a pre-existing issue, but while fixing the leak for I2C devices, it
looks like the identical leak was left behind in the I3C counterpart,
i3c_master_add_i3c_boardinfo().
However, would applying the same devm_add_action_or_reset() fix there
trigger a double-put use-after-free for instantiated I3C devices?
Looking at how the I3C devices are created, i3c_master_register_new_i3c_devs()
assigns the boardinfo fwnode to the new device without taking an additional
reference:
drivers/i3c/master.c:i3c_master_register_new_i3c_devs() {
...
device_set_node(&desc->dev->dev, desc->boardinfo->fwnode);
...
}
And when the device is unregistered, i3c_device_release() unconditionally
drops it:
drivers/i3c/master.c:i3c_device_release() {
...
fwnode_handle_put(dev->fwnode);
...
}
If a devm action is added to i3c_master_add_i3c_boardinfo() to drop the
reference on teardown, wouldn't we also need to add a fwnode_handle_get()
in i3c_master_register_new_i3c_devs() to ensure i3c_device_release()
doesn't consume the reference the devm action expects to drop?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260804101301.2975911-1-akhilrajeev@nvidia.com?part=1
--
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
next prev parent reply other threads:[~2026-08-04 10:33 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 10:12 [PATCH 0/5] i3c: Fix firmware node refcounting and error paths Akhil R
2026-08-04 10:12 ` Akhil R
2026-08-04 10:12 ` [PATCH 1/5] i3c: master: Release the fwnode of i2c boardinfo Akhil R
2026-08-04 10:12 ` Akhil R
2026-08-04 10:33 ` sashiko-bot [this message]
2026-08-05 19:07 ` Frank Li
2026-08-11 16:28 ` Akhil R
2026-08-04 16:53 ` Adrian Hunter
2026-08-04 16:53 ` Adrian Hunter
2026-08-04 10:12 ` [PATCH 2/5] i3c: master: Fix refcount of i3c fwnode Akhil R
2026-08-04 10:12 ` Akhil R
2026-08-04 16:53 ` Adrian Hunter
2026-08-04 16:53 ` Adrian Hunter
2026-08-04 10:12 ` [PATCH 3/5] i3c: master: Do not release the addresses when reattach fails Akhil R
2026-08-04 10:12 ` Akhil R
2026-08-04 17:56 ` Adrian Hunter
2026-08-04 17:56 ` Adrian Hunter
2026-08-04 10:13 ` [PATCH 4/5] i3c: dw: Do not use OF match data as a quirk bitmask Akhil R
2026-08-04 10:13 ` Akhil R
2026-08-04 11:04 ` sashiko-bot
2026-08-05 19:53 ` Frank Li
2026-08-05 19:53 ` Frank Li
2026-08-04 10:13 ` [PATCH 5/5] i3c: dw: Resume the controller before unregistering the bus Akhil R
2026-08-04 10:13 ` Akhil R
2026-08-04 11:15 ` sashiko-bot
2026-08-05 19:57 ` Frank Li
2026-08-05 19:57 ` Frank Li
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=20260804103306.A89B81F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=akhilrajeev@nvidia.com \
--cc=alexandre.belloni@bootlin.com \
--cc=linux-i3c@lists.infradead.org \
--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.