linux-kernel - Re: [PATCH] omap-cpufreq: Fix regulator resource leak in probe()

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <pjmwnxp6wae3bbmzmzys4r5szw6ywxphi4qtmpmg7jsqadc5fm@fvozoujr4mi5>
Date: Tue, 6 Jan 2026 10:20:55 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Andreas Kemnade <andreas@...nade.info>
Cc: Haotian Zhang <vulab@...as.ac.cn>, Kevin Hilman <khilman@...nel.org>, 
	"Rafael J . Wysocki" <rafael@...nel.org>, linux-omap@...r.kernel.org, linux-pm@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] omap-cpufreq: Fix regulator resource leak in probe()

On 05-01-26, 10:14, Andreas Kemnade wrote:
> On Mon, 15 Dec 2025 11:03:27 +0800
> Haotian Zhang <vulab@...as.ac.cn> wrote:
> 
> > The current omap_cpufreq_probe() uses regulator_get() to obtain the MPU
> > regulator but does not release it in omap_cpufreq_remove() or when
> > cpufreq_register_driver() fails, leading to a potential resource leak.
> > 
> > Use devm_regulator_get() instead of regulator_get() so that the regulator
> > resource is automatically released.
> > 
> > Fixes: 53dfe8a884e6 ("cpufreq: OMAP: scale voltage along with frequency")
> > Signed-off-by: Haotian Zhang <vulab@...as.ac.cn>
> > ---
> >  drivers/cpufreq/omap-cpufreq.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
> > index bbb01d93b54b..f83f85996b36 100644
> > --- a/drivers/cpufreq/omap-cpufreq.c
> > +++ b/drivers/cpufreq/omap-cpufreq.c
> > @@ -157,7 +157,7 @@ static int omap_cpufreq_probe(struct platform_device *pdev)
> >  		return -EINVAL;
> >  	}
> >  
> > -	mpu_reg = regulator_get(mpu_dev, "vcc");
> > +	mpu_reg = devm_regulator_get(mpu_dev, "vcc");
> >  	if (IS_ERR(mpu_reg)) {
> >  		pr_warn("%s: unable to get MPU regulator\n", __func__);
> >  		mpu_reg = NULL;
> > @@ -169,7 +169,6 @@ static int omap_cpufreq_probe(struct platform_device *pdev)
> >  		if (regulator_get_voltage(mpu_reg) < 0) {
> >  			pr_warn("%s: physical regulator not present for MPU\n",
> >  				__func__);
> > -			regulator_put(mpu_reg);
> 
> so it it not useable and could be released which is not done anymare 
> with your patch. It is not an error path here.

Right. Perhaps devm_regulator_put() here would be good enough.

> >  			mpu_reg = NULL;
> 
> And this should happen after removal, too. I feel some discomfort with
> variables pointing to freed ressources. So I think rather add
> the regulator_put and the = NULL to the remove function.

I don't see a reason why this extra step should be performed after the driver is
removed. `mpu_reg` can't be used after that.

-- 
viresh