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

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

[Karl Mehltretter]

imx6_soc_volt is allocated fresh on every probe, sized to the number of
ARM OPPs:

	imx6_soc_volt = devm_kcalloc(cpu_dev, num, sizeof(*imx6_soc_volt),
				     GFP_KERNEL);

but it is filled through soc_opp_count, which has static storage and is
never reset. A second bind after an unbind keeps indexing from where the
first one stopped, and writes past the end of the new array.

Unbinding and rebinding the driver on qemu's mcimx6ul-evk, under KASAN:

  BUG: KASAN: slab-out-of-bounds in imx6q_cpufreq_probe+0x3b0/0xa34
  Write of size 4 at addr c5e90480 by task binder/73
   imx6q_cpufreq_probe from platform_probe+0x88/0xe4
   platform_probe from really_probe+0x108/0x384
   bind_store from kernfs_fop_write_iter+0x1b4/0x28c

The write lands one u32 past the end of the allocation.

soc_opp_count is only read a few lines below the loop that fills it, so it
never needed static storage. Make it a local.

Fixes: b4573d1d657a ("cpufreq: imx6q: correct VDDSOC/PU voltage scaling when cpufreq is changed")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
 drivers/cpufreq/imx6q-cpufreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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)
 {
@@ -330,6 +329,7 @@ static int imx6q_cpufreq_probe(struct platform_device *pdev)
 	const struct property *prop;
 	const __be32 *val;
 	u32 nr, i, j;
+	u32 soc_opp_count = 0;
 
 	cpu_dev = get_cpu_device(0);
 	if (!cpu_dev) {
-- 
2.53.0

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

[sashiko-bot]

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 <kmehltretter@gmail.com>

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/20260806050239.90188-1-kmehltretter@gmail.com?part=1

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

[Viresh Kumar]

On 06-08-26, 07:02, Karl Mehltretter wrote:
> imx6_soc_volt is allocated fresh on every probe, sized to the number of
> ARM OPPs:
> 
> 	imx6_soc_volt = devm_kcalloc(cpu_dev, num, sizeof(*imx6_soc_volt),
> 				     GFP_KERNEL);
> 
> but it is filled through soc_opp_count, which has static storage and is
> never reset. A second bind after an unbind keeps indexing from where the
> first one stopped, and writes past the end of the new array.
> 
> Unbinding and rebinding the driver on qemu's mcimx6ul-evk, under KASAN:
> 
>   BUG: KASAN: slab-out-of-bounds in imx6q_cpufreq_probe+0x3b0/0xa34
>   Write of size 4 at addr c5e90480 by task binder/73
>    imx6q_cpufreq_probe from platform_probe+0x88/0xe4
>    platform_probe from really_probe+0x108/0x384
>    bind_store from kernfs_fop_write_iter+0x1b4/0x28c
> 
> The write lands one u32 past the end of the allocation.
> 
> soc_opp_count is only read a few lines below the loop that fills it, so it
> never needed static storage. Make it a local.
> 
> Fixes: b4573d1d657a ("cpufreq: imx6q: correct VDDSOC/PU voltage scaling when cpufreq is changed")
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
> ---
>  drivers/cpufreq/imx6q-cpufreq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied. Thanks.

-- 
viresh