Re: [PATCH v3 4/6] clk: nuvoton: ma35d1: Add missing WDT/WWDT parent clocks

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] clk: nuvoton: ma35d1: heap buffer overflow when assigning WDT/WWDT parent clocks
--

commit c77078104be2c7bd11ad595fff116aca53714922
Author: Miquel Raynal <miquel.raynal@bootlin.com>

clk: nuvoton: ma35d1: Add missing WDT/WWDT parent clocks

This commit adds missing WDT and WWDT parent clocks for the Nuvoton MA35D1
clock controller. It registers pclk3_div4096 and pclk4_div4096 as fixed
factor children of pclk3 and pclk4 to expose them through the provider.

Link: https://lore.kernel.org/linux-clk/b8a8a65b-e302-4747-bc90-4920fc48795a@gmail.com/

> diff --git a/drivers/clk/nuvoton/clk-ma35d1.c b/drivers/clk/nuvoton/clk-ma35d1.c
> index 6aa42a3e1be3b..5d706f5c30a59 100644
> --- a/drivers/clk/nuvoton/clk-ma35d1.c
> +++ b/drivers/clk/nuvoton/clk-ma35d1.c
> @@ -544,6 +544,8 @@ static int ma35d1_clocks_probe(struct platform_device *pdev)
>  	hws[HCLK3] = ma35d1_clk_fixed_factor(dev, "hclk3", "sysclk1_mux", 1, 2);
>  	hws[PCLK3] = ma35d1_clk_fixed_factor(dev, "pclk3", "sysclk1_mux", 1, 2);
>  	hws[PCLK4] = ma35d1_clk_fixed_factor(dev, "pclk4", "sysclk1_mux", 1, 2);
> +	hws[PCLK3_DIV4096] = ma35d1_clk_fixed_factor(dev, "pclk3_div4096", "pclk3", 1, 4096);
> +	hws[PCLK4_DIV4096] = ma35d1_clk_fixed_factor(dev, "pclk4_div4096", "pclk4", 1, 4096);

[Severity: High]
Does this code overflow the hws[] array?

Looking at the definitions in drivers/clk/nuvoton/clk-ma35d1.c,
MA35D1_CLK_COUNT is defined as 236:

#define MA35D1_CLK_COUNT 236

And in ma35d1_clocks_probe(), the array is allocated using this count:

	ma35d1_hw_data = devm_kzalloc(dev,
				      struct_size(ma35d1_hw_data, hws, MA35D1_CLK_COUNT),
				      GFP_KERNEL);
	if (!ma35d1_hw_data)
		return -ENOMEM;

	ma35d1_hw_data->num = MA35D1_CLK_COUNT;
	hws = ma35d1_hw_data->hws;

Since the hardcoded MA35D1_CLK_COUNT was not increased to accommodate the
two newly added clocks, will writing to PCLK3_DIV4096 (236) and
PCLK4_DIV4096 (237) cause an out-of-bounds heap write?

Additionally, because ma35d1_hw_data->num remains capped at
MA35D1_CLK_COUNT, does this leave the new clocks unregistered to external
dt-binding consumers?

>  
>  	hws[USBPHY0] = ma35d1_clk_fixed("usbphy0", 480000000);
>  	hws[USBPHY1] = ma35d1_clk_fixed("usbphy1", 480000000);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260925-perso-ma35d1-upstream-clk-v3-0-ffbae7e020a8@bootlin.com?part=4