The bus probing of the MDIO driver uses a two stage approach. 1. The device tree "ethernet-ports" node is scanned to build a mapping between ports and PHYs. 2. The children of the device tree "controller" are scanned to create the individual MDIO buses. The first step already checks the consistency of the PHY and bus nodes that are linked via the ports. But it might miss a dangling bus child node that is not linked. Step two simply iterates over all bus child nodes and might read malformed data from nodes not checked in step one. Harden this and return a meaningful error message. Signed-off-by: Markus Stockhausen --- drivers/net/mdio/mdio-realtek-rtl9300.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/net/mdio/mdio-realtek-rtl9300.c b/drivers/net/mdio/mdio-realtek-rtl9300.c index 517b01115f34..cec2afed5b6f 100644 --- a/drivers/net/mdio/mdio-realtek-rtl9300.c +++ b/drivers/net/mdio/mdio-realtek-rtl9300.c @@ -380,7 +380,11 @@ static int otto_emdio_probe_one(struct device *dev, struct otto_emdio_priv *priv err = fwnode_property_read_u32(node, "reg", &mdio_bus); if (err) - return err; + return dev_err_probe(dev, err, "undefined smi bus number\n"); + + if (mdio_bus >= priv->info->num_buses) + return dev_err_probe(dev, -EINVAL, + "illegal (dangling) smi bus number %d\n", mdio_bus); /* The MDIO accesses from the kernel work with the PHY polling unit in * the switch. We need to tell the PPU to operate either in GPHY (i.e. -- 2.54.0