linux-kernel - Re: [PATCH] cpufreq: apple-soc: Fix possible null pointer dereference

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

Message-ID: <86v7r4jtiu.wl-maz@kernel.org>
Date: Wed, 16 Apr 2025 11:22:01 +0100
From: Marc Zyngier <maz@...nel.org>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: rafael@...nel.org,
	Chenyuan Yang <chenyuan0y@...il.com>,
	sven@...npeter.dev,
	j@...nau.net,
	alyssa@...enzweig.io,
	neal@...pa.dev,
	marcan@...can.st,
	asahi@...ts.linux.dev,
	linux-arm-kernel@...ts.infradead.org,
	linux-pm@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cpufreq: apple-soc: Fix possible null pointer dereference

On Wed, 16 Apr 2025 08:34:20 +0100,
Viresh Kumar <viresh.kumar@...aro.org> wrote:
> 
> On 13-04-25, 11:02, Marc Zyngier wrote:
> > Irrespective of this, it would be good to describe under which
> > circumstances this can occur, because I can't see *how* this can
> > trigger. The policy is directly provided by the core code and provide
> > its association with a cpu, and is never NULL at the point of init.
> > 
> > And if it can trigger, why only fix this one particular case?
> > Dereferences of policy are all over the map, and would be just as
> > wrong.
> > 
> > So while this is not wrong, I don't think this serves any real
> > purpose.
> 
> I have applied such patches in the past, considering the same as good
> practice. But I do understand your inputs.
> 
> And so I tried to see if there is actually a way to trigger this.
> 
> - Platform with two cpufreq policies (freq domains) with one CPU in
>   each of them.
> - Boot the kernel, policies will initialize for both the domains.
> - Hotplug out CPU1, that will remove the policy as well.
> - Call cpufreq_quick_get(1), this will call the ->get() callback for
>   CPU1, for which there is no policy available.
> 
> But this is the case only for drivers with `setpolicy` callback, this
> shouldn't happen on apple-soc.
> 
> I am not sure now if we should just apply this patch to be safe, or
> leave it as is. The cpufreq core may change in the future and call the
> `get` callback for all drivers.

If that's the case, I'd suggest adding a __must_check annotation to
cpufreq_cpu_get_raw() and co. At least we'll get a warning on all
missing uses, fix them in one go, and avoid the constant churn of more
or less correct patches.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.