Re: [PATCH net-next v13 04/11] net: mdio: realtek-rtl9300: suppress sysfs bind/unbind attributes

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

Pre-existing issues:
- [High] Incomplete mitigation for a use-after-free vulnerability: `suppress_bind_attrs = true` does not prevent UAF during probe failures or parent device removal.
--

--- Patch [4]: [PATCH net-next v13 04/11] net: mdio: realtek-rtl9300: suppress sysfs bind/unbind attributes ---
commit 5daa031cbe196a78cb58053e9b33430ed4fb2104
Author: Markus Stockhausen <[email protected]>
Subject: net: mdio: realtek-rtl9300: suppress sysfs bind/unbind attributes

This commit aims to mitigate a use-after-free issue by setting
suppress_bind_attrs to true, preventing sysfs unbinds on this specific driver
instance. It notes that a corrupt devicetree might produce a load failure and
a cleanup too, and that the mdiobus may outlive the devm-allocated controller
structure.

> diff --git a/drivers/net/mdio/mdio-realtek-rtl9300.c b/drivers/net/mdio/mdio-realtek-rtl9300.c
> index 73ac5fdcd2674..1873928b362dd 100644
> --- a/drivers/net/mdio/mdio-realtek-rtl9300.c
> +++ b/drivers/net/mdio/mdio-realtek-rtl9300.c
> @@ -830,6 +830,7 @@ static struct platform_driver otto_emdio_driver = {
>  	.driver = {
>  		.name = "mdio-rtl9300",
>  		.of_match_table = otto_emdio_ids,
> +		.suppress_bind_attrs = true,

[Severity: High]
This isn't a bug introduced by this patch, but does this mitigation fully
address the use-after-free vulnerability?

The commit message correctly notes that a corrupt devicetree can produce a
load failure. If otto_emdio_probe() successfully registers the first bus but
fails on a subsequent child node, the driver will unwind its devres
allocations:

drivers/net/mdio/mdio-realtek-rtl9300.c:otto_emdio_probe() {
    ...
	device_for_each_child_node_scoped(dev, child) {
		err = otto_emdio_probe_one(dev, priv, child);
		if (err)
			return err;
	}
    ...
}

If this happens, the central priv structure (allocated via devm_kzalloc) is
freed by devres. A concurrently probing MAC driver could have already acquired
a reference to a PHY on the successfully registered first bus, which will keep
the mii_bus alive.

When the MAC driver subsequently accesses the PHY, could it trigger a
use-after-free by attempting to access the freed priv pointer?

Setting suppress_bind_attrs to true only prevents manual sysfs unbinds on this
specific child driver instance. Will this leave the probe-failure and parent
device removal use-after-free paths exposed?

>  	},
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=4