From: sashiko-bot@kernel.org
To: "Ahmad Byagowi" <ahmadexp@gmail.com>
Cc: robh@kernel.org, linux-leds@vger.kernel.org, lee@kernel.org,
conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH net-next v4 3/5] i2c: mux: Propagate software nodes to channel adapters
Date: Thu, 13 Aug 2026 14:17:38 +0000 [thread overview]
Message-ID: <20260813141739.2D1031F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <e962f3ba58a44cbec8e1f0cfae321d5c8d99d8b6.1786543681.git.ahmadexp@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing device_remove_software_node() during normal adapter teardown leads to Use-After-Free.
--
--- Patch [3]: [PATCH net-next v4 3/5] i2c: mux: Propagate software nodes to channel adapters ---
commit dcd183b53494f861ae352813bfad4b50641126b5
Author: Ahmad Byagowi <ahmadexp@gmail.com>
i2c: mux: Propagate software nodes to channel adapters
This commit associates equivalent software-node descriptions with adapters
created by i2c-mux. It finds the software-node child whose reg value matches
the channel and assigns it to the new adapter.
> diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
> index 681a201c239ba..040284236275f 100644
> --- a/drivers/i2c/i2c-mux.c
> +++ b/drivers/i2c/i2c-mux.c
[ ... ]
> @@ -374,6 +429,16 @@ int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
> ACPI_COMPANION(muxc->dev),
> chan_id);
>
> + if (channel_node) {
> + ret = device_add_software_node(&priv->adap.dev,
> + to_software_node(channel_node));
> + if (!ret)
> + priv->swnode = channel_node;
> + fwnode_handle_put(channel_node);
> + if (ret)
> + goto err_free_priv;
> + }
> +
[ ... ]
> @@ -430,6 +496,7 @@ void i2c_mux_del_adapters(struct i2c_mux_core *muxc)
>
> sysfs_remove_link(&priv->adap.dev.kobj, "mux_device");
> i2c_del_adapter(adap);
> + fwnode_handle_put(priv->swnode);
[Severity: High]
Does this create a dangling fwnode pointer in the device object, leading to a
use-after-free?
In i2c_mux_add_adapter(), the software node is attached to the adapter using
device_add_software_node(), which takes an internal reference and sets the
device's secondary fwnode. The driver properly drops its local reference
immediately via fwnode_handle_put(channel_node).
During normal teardown here in i2c_mux_del_adapters(), should this call
device_remove_software_node(&priv->adap.dev) instead of bypassing the API and
manually calling fwnode_handle_put(priv->swnode)?
Manually calling fwnode_handle_put() here drops the internal reference
acquired by the device core, freeing the software node while the device's
secondary fwnode pointer still points to it (because
device_remove_software_node() was never called to clear it). If the
unregistered device object is kept alive by other concurrent reference
holders, accessing its fwnode will result in a use-after-free.
> of_node_put(np);
> kfree(priv);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1786543681.git.ahmadexp@gmail.com?part=3
next prev parent reply other threads:[~2026-08-13 14:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 14:17 [PATCH net-next v4 0/5] ptp: ocp: Add R4006 and V9 I2C peripheral support Ahmad Byagowi
2026-08-12 14:17 ` [PATCH net-next v4 1/5] dt-bindings: leds: Add IS32FL3207 controller Ahmad Byagowi
2026-08-13 14:17 ` sashiko-bot
2026-08-12 14:17 ` [PATCH net-next v4 2/5] leds: is32fl3207: Add controller driver Ahmad Byagowi
2026-08-13 14:17 ` sashiko-bot
2026-08-12 14:17 ` [PATCH net-next v4 3/5] i2c: mux: Propagate software nodes to channel adapters Ahmad Byagowi
2026-08-13 14:17 ` sashiko-bot [this message]
2026-08-12 14:17 ` [PATCH net-next v4 4/5] ptp: ocp: Add R4006 I2C peripheral topology Ahmad Byagowi
2026-08-13 14:17 ` sashiko-bot
2026-08-13 22:20 ` Vadim Fedorenko
2026-08-12 14:17 ` [PATCH net-next v4 5/5] ptp: ocp: Add Time Card V9 " Ahmad Byagowi
2026-08-13 14:17 ` sashiko-bot
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=20260813141739.2D1031F00A3D@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=ahmadexp@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=lee@kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=robh@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