Re: [PATCH] cpufreq: imx6q: fix out-of-bounds write when probed more than once

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

Pre-existing issues:
- [High] Hardware clock state desynchronization and unhandled clock reference leak on error path in `imx6q_set_target`.
--

--- Patch [1]: [PATCH] cpufreq: imx6q: fix out-of-bounds write when probed more than once ---
commit eaf7ff016f231691af46156c1e76ffcc234120eb
Author: Karl Mehltretter <[email protected]>

cpufreq: imx6q: fix out-of-bounds write when probed more than once

This commit fixes an out-of-bounds array write during probe caused by
soc_opp_count retaining state across driver unbinds and rebinds. Moving
soc_opp_count to a local variable ensures the array index resets properly
on every initialization.

> diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
> index e93697d3edfd9..fe0453c9623fb 100644
> --- a/drivers/cpufreq/imx6q-cpufreq.c
> +++ b/drivers/cpufreq/imx6q-cpufreq.c
> @@ -55,7 +55,6 @@ static unsigned int max_freq;
>  static unsigned int transition_latency;
>  
>  static u32 *imx6_soc_volt;
> -static u32 soc_opp_count;
>  
>  static int imx6q_set_target(struct cpufreq_policy *policy, unsigned int index)
>  {

[Severity: High]
This is a pre-existing issue, but does the error handling in
imx6q_set_target() leave the hardware in an inconsistent state?

When the cpufreq core calls imx6q_set_target(), it sets
pll1_sys_temp_enabled and calls clk_prepare_enable() without checking
its return value:

	/* pll1_sys needs to be enabled for divider rate change to work. */
	pll1_sys_temp_enabled = true;
	clk_prepare_enable(clks[PLL1_SYS].clk);

Then, if setting the new arm clock rate fails, it restores the old voltage:

	/* Ensure the arm clock divider is what we expect */
	ret = clk_set_rate(clks[ARM].clk, new_freq * 1000);
	if (ret) {
		int ret1;

		dev_err(cpu_dev, "failed to set clock rate: %d\n", ret);
		ret1 = regulator_set_voltage_tol(arm_reg, volt_old, 0);
...
		return ret;
	}

If scaling up to a higher frequency, volt_old is lower than the required
voltage. Since the hardware clock tree (e.g. PLL1_SW) has already been
reprogrammed and reparented to the new higher frequency earlier in the
function, does restoring volt_old without rolling back the clock mux state
cause a CPU undervolt and subsequent system crash?

Also, does returning early from this error path leak the clk_prepare_enable()
reference since the clk_disable_unprepare() cleanup is skipped?

[ ... ]

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