Re: [PATCH v2 19/35] clk: mediatek: mt6779: Switch to common probe/remove helpers

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] clk: heap buffer overflow during clock registration due to sparse IDs
--

commit 667fb3289a24a54cc5cde32a40e6a991c9fdb902
Author: Akari Tsuyukusa <akkun11.open@gmail.com>

clk: mediatek: mt6779: Switch to common probe/remove helpers
    
The MT6779 apmixedsys driver used a custom probe to register PLLs.
With PLL registration now supported by the common helpers, it can use
mtk_clk_simple_probe() and mtk_clk_simple_remove().

> diff --git a/drivers/clk/mediatek/clk-mt6779.c b/drivers/clk/mediatek/clk-mt6779.c
> index 4b9dcb910b03f..a806789ae27c1 100644
> --- a/drivers/clk/mediatek/clk-mt6779.c
> +++ b/drivers/clk/mediatek/clk-mt6779.c
[ ... ]
> @@ -1211,125 +1209,47 @@ static const struct mtk_pll_data plls[] = {
>  	    0, 0, 32, 8, 0x02D4, 1, 0, 0x14, 1, 0x02D8, 0, 0x02D4),
>  };
>  
> -static int clk_mt6779_apmixed_probe(struct platform_device *pdev)
> -{
> -	struct clk_hw_onecell_data *clk_data;
> -	struct device_node *node = pdev->dev.of_node;
> -
> -	clk_data = mtk_alloc_clk_data(CLK_APMIXED_NR_CLK);
> -	if (!clk_data)
> -		return -ENOMEM;
> -
> -	mtk_clk_register_plls(&pdev->dev, plls, ARRAY_SIZE(plls), clk_data);
> -
> -	mtk_clk_register_gates(&pdev->dev, node, apmixed_clks,
> -			       ARRAY_SIZE(apmixed_clks), clk_data);
> -
> -	return of_clk_add_hw_provider(node, of_clk_hw_onecell_get, clk_data);
> -}
> -
> -static int clk_mt6779_top_probe(struct platform_device *pdev)
> -{
> -	void __iomem *base;
> -	struct clk_hw_onecell_data *clk_data;
> -	struct device_node *node = pdev->dev.of_node;
> -
> -	base = devm_platform_ioremap_resource(pdev, 0);
> -	if (IS_ERR(base))
> -		return PTR_ERR(base);
> -
> -	clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
> -	if (!clk_data)
> -		return -ENOMEM;
> -
> -	mtk_clk_register_fixed_clks(top_fixed_clks, ARRAY_SIZE(top_fixed_clks),
> -				    clk_data);
> -
> -	mtk_clk_register_factors(top_divs, ARRAY_SIZE(top_divs), clk_data);
> -
> -	mtk_clk_register_muxes(&pdev->dev, top_muxes,
> -			       ARRAY_SIZE(top_muxes), node,
> -			       &mt6779_clk_lock, clk_data);
> -
> -	mtk_clk_register_composites(&pdev->dev, top_aud_muxes,
> -				    ARRAY_SIZE(top_aud_muxes), base,
> -				    &mt6779_clk_lock, clk_data);
> -
> -	mtk_clk_register_composites(&pdev->dev, top_aud_divs,
> -				    ARRAY_SIZE(top_aud_divs), base,
> -				    &mt6779_clk_lock, clk_data);
> -
> -	return of_clk_add_hw_provider(node, of_clk_hw_onecell_get, clk_data);
> -}
> -
[ ... ]
> +static const struct mtk_clk_desc apmixed_desc = {
> +	.clks = apmixed_clks,
> +	.num_clks = ARRAY_SIZE(apmixed_clks),
> +	.plls = plls,
> +	.num_plls = ARRAY_SIZE(plls),
>  };
>  
> +static const struct mtk_clk_desc topck_desc = {
> +	.fixed_clks = top_fixed_clks,
> +	.num_fixed_clks = ARRAY_SIZE(top_fixed_clks),
> +	.factor_clks = top_divs,
> +	.num_factor_clks = ARRAY_SIZE(top_divs),
> +	.mux_clks = top_muxes,
> +	.num_mux_clks = ARRAY_SIZE(top_muxes),
> +	.composite_clks = top_aud_muxes_divs,
> +	.num_composite_clks = ARRAY_SIZE(top_aud_muxes_divs),
> +	.clk_lock = &mt6779_clk_lock,
> +};

[Severity: High]
Does this struct initialization fail to account for sparse DT binding IDs?

The previous code allocated clk_data using a maximum bounds macro, for
example mtk_alloc_clk_data(CLK_TOP_NR_CLK).

By switching to mtk_clk_simple_probe(), it appears __mtk_clk_simple_probe()
calculates the number of clocks by simply summing the array sizes (e.g.
num_fixed_clks + num_factor_clks + ...), which may total fewer than 100
elements.

However, the clock registration functions like mtk_clk_register_composites()
write directly into clk_data->hws[mc->id] = hw, where mc->id uses the sparse
DT binding IDs (such as CLK_TOP_UNIVPLL_D3_D16, which is 152).

Can this overflow the dynamically allocated clk_data->hws flexible array and
corrupt heap memory during probe?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261013151734.3177690-1-akkun11.open@gmail.com?part=19