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

[netdev-bot+sashiko@kernel.org]

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