[PATCH net] net: tn40xx: fix swnode use-after-free on probe failure

[PATCH net] net: tn40xx: fix swnode use-after-free on probe failure

[Johan Hovold]

The mdiobus allocated by tn40_mdiobus_init() has no primary firmware
node so its firmware node pointer points to the secondary software node
added by device_add_software_node() and whose reference is released by
device_remove_software_node().

Drop the stray firmware node reference decrement on probe failure and
driver unbind which leads to a use-after-free when deregistering the
software node group as the parent MDIO node has been freed before the
child PHY node.

Fixes: 25b6a6d29d40 ("net: tn40xx: create swnode for mdio and aqr105 phy and add to mdiobus")
Cc: stable@vger.kernel.org	# 6.15
Cc: Hans-Frieder Vogt <hfdevel@gmx.net>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/net/ethernet/tehuti/tn40_mdio.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/tehuti/tn40_mdio.c b/drivers/net/ethernet/tehuti/tn40_mdio.c
index fb1a4a2e4dbc..49951477ac05 100644
--- a/drivers/net/ethernet/tehuti/tn40_mdio.c
+++ b/drivers/net/ethernet/tehuti/tn40_mdio.c
@@ -157,7 +157,6 @@ void tn40_swnodes_cleanup(struct tn40_priv *priv)
 {
 	/* cleanup of swnodes is only needed for AQR105-based cards */
 	if (priv->pdev->device == PCI_DEVICE_ID_TEHUTI_TN9510) {
-		fwnode_handle_put(dev_fwnode(&priv->mdio->dev));
 		device_remove_software_node(&priv->mdio->dev);
 		software_node_unregister_node_group(priv->nodes.group);
 	}
-- 
2.56.0

Re: [PATCH net] net: tn40xx: fix swnode use-after-free on probe failure

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

 - What hardware the change was tested on. For driver fixes please
   mention the device (and if relevant firmware version) used for
   testing, or say that the change was not tested on real hardware.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net] net: tn40xx: fix swnode use-after-free on probe failure

[Johan Hovold]

On Tue, Nov 10, 2026 at 10:06:52AM +0000, netdev-bot+sinfo@kernel.org wrote:

> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
> 
>  - How the issue was discovered, e.g. hit in production, hit during
>    development, syzbot report, manual code inspection, LLM or static
>    analysis tool scan.
>
>  - Whether the issue was actually triggered, or is only theoretical
>    (e.g. found by code inspection). If it was triggered please include
>    the symptoms, like the stack trace or error messages.
>
>  - What hardware the change was tested on. For driver fixes please
>    mention the device (and if relevant firmware version) used for
>    testing, or say that the change was not tested on real hardware.

This was found through inspection when reviewing users of
device_set_software_node() and has only been compile tested.

Johan

Re: [PATCH net] net: tn40xx: fix swnode use-after-free on probe failure

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 1 · Medium: 0 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [High] The patch rests on a wrong premise and adds a refcount leak of
  the MDIO software node, along with a dangling pointer into freed…

--

net: tn40xx: fix swnode use-after-free on probe failure

This commit removes the fwnode_handle_put() of the MDIO bus firmware node
from tn40_swnodes_cleanup() and calls it a stray reference decrement. The
commit message says this put causes a use-after-free when the software
node group is unregistered on probe failure and on driver unbind.

> diff --git a/drivers/net/ethernet/tehuti/tn40_mdio.c b/drivers/net/ethernet/tehuti/tn40_mdio.c
> index fb1a4a2e4dbc5..49951477ac052 100644
> --- a/drivers/net/ethernet/tehuti/tn40_mdio.c
> +++ b/drivers/net/ethernet/tehuti/tn40_mdio.c
> @@ -157,7 +157,6 @@ void tn40_swnodes_cleanup(struct tn40_priv *priv)
>  {
>  	/* cleanup of swnodes is only needed for AQR105-based cards */
>  	if (priv->pdev->device == PCI_DEVICE_ID_TEHUTI_TN9510) {
> -		fwnode_handle_put(dev_fwnode(&priv->mdio->dev));

[Severity: High]
Is this put really stray? It seems to balance the reference that the MDIO
core takes on the bus fwnode when the bus is registered:

drivers/net/phy/mdio_bus_provider.c:__mdiobus_register() {
    ...
	if (bus->state == MDIOBUS_ALLOCATED)
		fwnode_handle_get(dev_fwnode(&bus->dev));
    ...
}

The bus has no primary fwnode, so dev_fwnode(&bus->dev) is the tn40 MDIO
swnode here. The core expects to drop that reference in mdiobus_release():

drivers/net/phy/mdio_bus_provider.c:mdiobus_release() {
    ...
	if (bus->state == MDIOBUS_RELEASED)
		fwnode_handle_put(dev_fwnode(d));
    ...
}

However, tn40_remove() and the err_cleanup_swnodes path in tn40_probe()
call tn40_swnodes_cleanup() before devres runs devm_mdiobus_unregister()
and devm_mdiobus_free(). In tn40_swnodes_cleanup(),
device_remove_software_node() calls set_secondary_fwnode(dev, NULL). The
swnode is not primary, so this sets bus->dev.fwnode to NULL. By the time
mdiobus_release() runs, its put is fwnode_handle_put(NULL), which does
nothing.

Here is the refcount of the MDIO swnode kobject after a successful probe:

  software_node_register()               1
  child PHY swnode kobject parent ref    2
  device_add_software_node()             3
  __mdiobus_register() get               4
  device_add()->software_node_notify()   5

Without the removed put, tn40_swnodes_cleanup() drops three of these
(notify_remove, swnode_put, and software_node_unregister). The PHY child
release drops the parent ref. That leaves the MDIO swnode at 1 forever.

With the put in place, the count reached exactly zero. kobject_cleanup()
only drops the parent after the child's release has finished. Given that,
where does the use-after-free in the commit message come from?

  "the parent MDIO node has been freed before the child PHY node"

After this change, does every TN9510 unbind, module unload, or probe
failure after __mdiobus_register() leak the MDIO swnode?

That leak would have these effects:

The tn40_mdio-<id> node stays registered under /sys/kernel/software_nodes.
The next probe's software_node_register_node_group() then fails with
-EEXIST, either through software_node_to_swnode() or through a duplicate
kobject name. The card cannot be bound again until reboot.

The leaked swnode's ->node points into tn40_priv->nodes.swnodes[], which
devres frees. software_node_find_by_name() dereferences
swnode->node->parent and swnode->node->name for every registered node, so
it would read freed memory.

device_add() set swnode->fwnode.dev to &bus->dev. device_del() never
clears it, because dev->fwnode is already NULL by then. The leaked node
would keep a dangling pointer to the freed mii_bus.

The same core get/put pair already exists at 25b6a6d29d40 (in
mdio_bus.c), so the 6.15 stable backport would bring the same leak.

Could the fix account for the core's reference instead of dropping the
put? For example, bus->dev.fwnode could stay set until mdiobus_release()
has run.

>  		device_remove_software_node(&priv->mdio->dev);
>  		software_node_unregister_node_group(priv->nodes.group);
>  	}

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261110100051.2567443-1-johan%40kernel.org