From: sashiko-bot@kernel.org
To: "Adrian Hunter" <adrian.hunter@intel.com>
Cc: linux-pci@vger.kernel.org,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
linux-i3c@lists.infradead.org, Frank.Li@kernel.org
Subject: Re: [PATCH V5 04/14] i3c: master: Fix use-after-free of master->this
Date: Fri, 07 Aug 2026 15:14:00 +0000 [thread overview]
Message-ID: <20260807151401.8ACEF1F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260807145638.168865-5-adrian.hunter@intel.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Pre-existing devres lifetime mismatch causing Use-After-Free in i3c_masterdev_release(), exacerbated by the patch's newly added kfree().
- [High] Pre-existing IDR state corruption due to missing error handling around i3cbus->id in probe failure path.
--
--- Patch [4]: [PATCH V5 04/14] i3c: master: Fix use-after-free of master->this ---
commit aad15513dbf2d559bf893789d55a331f522383d1
Author: Adrian Hunter <adrian.hunter@intel.com>
Subject: i3c: master: Fix use-after-free of master->this
The patch fixes a use-after-free by keeping master->this alive until
i3c_masterdev_release(). It also resets master->this and bus.cur_master to
NULL on the error path in i3c_master_set_info() before freeing the
allocated device.
Cc: stable@vger.kernel.org
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index abb582645a2ed..2357874bb9d6a 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c
> @@ -842,6 +842,11 @@ static struct attribute *i3c_masterdev_attrs[] = {
> };
> ATTRIBUTE_GROUPS(i3c_masterdev);
>
> +static void i3c_master_free_i3c_dev(struct i3c_dev_desc *dev)
> +{
> + kfree(dev);
> +}
> +
> static void i3c_masterdev_release(struct device *dev)
> {
> struct i3c_master_controller *master = dev_to_i3cmaster(dev);
> @@ -854,6 +859,8 @@ static void i3c_masterdev_release(struct device *dev)
> i3c_bus_cleanup(bus);
[Severity: High]
This isn't a bug introduced by this patch, but does the error path in probe
corrupt the IDR if idr_alloc() fails?
If idr_alloc() fails in i3c_bus_init(), i3cbus->id is not updated and remains
at its kzalloc-initialized value of 0.
The error path in i3c_master_register() calls put_device(&master->dev), which
invokes this i3c_masterdev_release() callback.
That unconditionally calls i3c_bus_cleanup(bus), which executes
idr_remove(&i3c_bus_idr, i3cbus->id). This effectively deletes ID 0 from the
IDR, even though that ID might belong to another successfully initialized bus.
>
> fwnode_handle_put(dev->fwnode);
> +
> + i3c_master_free_i3c_dev(master->this);
[Severity: High]
This is a pre-existing issue, but can this devres lifetime mismatch lead
to a use-after-free when sysfs files are held open?
The i3c_master_controller struct is typically allocated via devm_kzalloc()
by the parent driver. If an unprivileged user holds a sysfs file open (like
the mode or current_master attributes), device_unregister() drops a
reference, but the sysfs node prevents the kobject from being released.
When the driver is unbound and remove() returns, devres frees the master
struct.
Later, when the sysfs file is closed, the refcount drops to 0 and
i3c_masterdev_release() executes, dereferencing the already-freed master
struct to access master->wq, bus, and the newly added
i3c_master_free_i3c_dev(master->this).
> }
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260807145638.168865-1-adrian.hunter@intel.com?part=4
--
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-07 15:14 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-07 14:56 [PATCH V5 00/14] i3c: Support IBI-based system wakeup Adrian Hunter
2026-08-07 14:56 ` [PATCH V5 01/14] i3c: master: Fix recursive locking during device registration Adrian Hunter
2026-08-07 15:26 ` sashiko-bot
2026-08-07 14:56 ` [PATCH V5 02/14] i3c: Fix unlocked dereference of dev->desc in i3c_device_get_supported_xfer_mode() Adrian Hunter
2026-08-07 15:13 ` sashiko-bot
2026-08-07 14:56 ` [PATCH V5 03/14] i3c: master: Do not treat master device as a duplicate target Adrian Hunter
2026-08-07 15:07 ` sashiko-bot
2026-08-07 14:56 ` [PATCH V5 04/14] i3c: master: Fix use-after-free of master->this Adrian Hunter
2026-08-07 15:14 ` sashiko-bot [this message]
2026-08-07 14:56 ` [PATCH V5 05/14] i3c: Make dev->desc locking assumptions explicit Adrian Hunter
2026-08-07 15:20 ` sashiko-bot
2026-08-07 14:56 ` [PATCH V5 06/14] i3c: master: Fix potential UAF in i3c_device_uevent() Adrian Hunter
2026-08-07 15:21 ` sashiko-bot
2026-08-07 14:56 ` [PATCH V5 07/14] i3c: master: Fix potential UAF in i3c_device_match() Adrian Hunter
2026-08-07 15:37 ` sashiko-bot
2026-08-07 19:43 ` Frank Li
2026-08-08 13:07 ` Alexandre Belloni
2026-08-07 14:56 ` [PATCH V5 08/14] i3c: master: Support IBI-based wakeup capability Adrian Hunter
2026-08-07 15:16 ` sashiko-bot
2026-08-07 14:56 ` [PATCH V5 09/14] i3c: master: Report wakeup events for IBIs Adrian Hunter
2026-08-07 15:41 ` sashiko-bot
2026-08-07 14:56 ` [PATCH V5 10/14] i3c: master: Add helper to query bus wakeup requirements Adrian Hunter
2026-08-07 15:21 ` sashiko-bot
2026-08-07 14:56 ` [PATCH V5 11/14] i3c: master: Reject IBI requests from non-IBI-capable devices Adrian Hunter
2026-08-07 15:26 ` sashiko-bot
2026-08-07 14:56 ` [PATCH V5 12/14] i3c: mipi-i3c-hci-pci: Propagate I3C wakeup requirements to PCI Adrian Hunter
2026-08-07 15:38 ` sashiko-bot
2026-08-07 14:56 ` [PATCH V5 13/14] i3c: mipi-i3c-hci: Factor out i3c_hci_sysdev() Adrian Hunter
2026-08-07 15:40 ` sashiko-bot
2026-08-07 14:56 ` [PATCH V5 14/14] i3c: mipi-i3c-hci: Advertise IBI wakeup capability Adrian Hunter
2026-08-07 15:30 ` sashiko-bot
2026-08-08 13:09 ` [PATCH V5 00/14] i3c: Support IBI-based system wakeup Alexandre Belloni
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=20260807151401.8ACEF1F00A3D@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexandre.belloni@bootlin.com \
--cc=linux-i3c@lists.infradead.org \
--cc=linux-pci@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox