netdev - [PATCH net-next v1] net: stmmac: initialize the reset delay array

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 18 Jun 2019 22:39:27 +0200
From:   Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To:     netdev@...r.kernel.org, davem@...emloft.net
Cc:     linux-kernel@...r.kernel.org, joabreu@...opsys.com,
        alexandre.torgue@...com, peppe.cavallaro@...com,
        khilman@...libre.com,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Subject: [PATCH net-next v1] net: stmmac: initialize the reset delay array

Commit ce4ab73ab0c27c ("net: stmmac: drop the reset delays from struct
stmmac_mdio_bus_data") moved the reset delay array from struct
stmmac_mdio_bus_data to a stack variable.
The values from the array inside struct stmmac_mdio_bus_data were
previously initialized to 0 because the struct was allocated using
devm_kzalloc(). The array on the stack has to be initialized
explicitly, else we might be reading garbage values.

Initialize all reset delays to 0 to ensure that the values are 0 if the
"snps,reset-delays-us" property is not defined.
This fixes booting at least two boards (MIPS pistachio marduk and ARM
sun8i H2+ Orange Pi Zero). These are hanging during boot when
initializing the stmmac Ethernet controller (as found by Kernel CI).
Both have in common that they don't define the "snps,reset-delays-us"
property.

Fixes: ce4ab73ab0c27c ("net: stmmac: drop the reset delays from struct stmmac_mdio_bus_data")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
---
On my Amlogic boards the delay values are 0 even without this patch.
I may have been lucky with my kernel build that I'm not triggering
the same fault as Kernel CI found on the two boards mentioned here: [0]

Please feel free to squash this into net-next commit ce4ab73ab0c27c.

[0] https://lore.kernel.org/netdev/7hr27qdedo.fsf@baylibre.com/T/#u

 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index da310de06bf6..18cadf0b0d66 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -241,7 +241,7 @@ int stmmac_mdio_reset(struct mii_bus *bus)
 #ifdef CONFIG_OF
 	if (priv->device->of_node) {
 		struct gpio_desc *reset_gpio;
-		u32 delays[3];
+		u32 delays[3] = { 0, 0, 0 };

 		reset_gpio = devm_gpiod_get_optional(priv->device,
 						     "snps,reset",
-- 
2.22.0