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: <y2xyyyyhdoxflj4doa4y3a7prjqulcw63bdkor3fo3qsbmxvzy@dvhmfxkkzdqs>
Date: Wed, 7 Jan 2026 11:27:42 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Andreas Kemnade <andreas@...nade.info>, Nishanth Menon <nm@...com>, 
	Kevin Hilman <khilman@...nel.org>
Cc: Haotian Zhang <vulab@...as.ac.cn>, 
	"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 06-01-26, 18:29, Andreas Kemnade wrote:
> hmm, it is performed when the device is removed/unbound, which does not necessarily
> mean the driver is removed.

For the cpufreq drivers, the device is normally never removed. It either gets
created from DT or some platform specific code creates the device for ever. But
anyway, we were both talking about unbound being called, doesn't matter if it is
the device or driver which is removed.

> But that does not prevent trouble if something
> is still trying to access stuff here after driver removal. So it is not really
> helpful.

It is not possible for something to still be using the resources from this
driver (like the global variables) after remove() is called. If there is a bug
in there, then that needs to be fixed instead.

> Hmm, how does a device gets bound to this driver?

Nice catch.

Tried to look at history.

commit cb6675d6a868 ("ARM: OMAP2+: Remove legacy PM init")

This commit removed the platform device being created and mentions that stuff
happens via DT, which AFAIU, creates the cpufreq-dt device instead.

So no one should be using this driver since year 2016.

Kevin, Nishanth, can you please confirm ? We should remove this driver.

> But the fix is good for stable. So I would propose to add this
> fix (to let it propagate to stable) and deorbit this driver.

I don't think it is worth adding to stable when there are no users.

-- 
viresh