Linux LED subsystem development
 help / color / mirror / Atom feed
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

  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