linux-kernel - Re: CVE-2025-37832: cpufreq: sun50i: prevent out-of-bounds access

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: <2025060418-reappoint-outward-d414@gregkh>
Date: Wed, 4 Jun 2025 09:44:26 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Giovanni Gherdovich <giovanni.gherdovich@...e.com>
Cc: Andre Przywara <andre.przywara@....com>, cve@...nel.org,
	linux-kernel@...r.kernel.org, Yangtao Li <tiny.windzz@...il.com>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Viresh Kumar <viresh.kumar@...aro.org>
Subject: Re: CVE-2025-37832: cpufreq: sun50i: prevent out-of-bounds access

On Mon, Jun 02, 2025 at 06:28:31PM +0200, Giovanni Gherdovich wrote:
> Hello,
> 
> On Mon Jun 2, 2025 14:51, Andre Przywara wrote:
> > 
> > Hi,
> > 
> > I don't think this qualifies as a CVE, the issue was more theoretical. But
> > I don't have much experience with what deserves a CVE and what not, so I
> > can just present some insights:
> > 
> > > > > On Fri, May 30, 2025 at 03:57:35PM +0200, Giovanni Gherdovich wrote:
> > > > > > On Thu May 8, 2025 08:39, Greg Kroah-Hartman wrote:
> > > > > > > A KASAN enabled kernel reports an out-of-bounds access when handling the
> > > > > > > nvmem cell in the sun50i cpufreq driver:
> > > > > > > [...]
> > > > > > 
> > > > > > The invalid data that may be read comes from a ROM in the SoC,
> > > > > > programmed by the vendor, and is only used to configure CPU frequency
> > > > > > and voltage in the cpufreq framework.
> > 
> > So "potentially invalid data read from the ROM" is an issue the we have
> > regardless, this patch doesn't change that. And you cannot put arbitrary
> > voltages or frequencies in the OTP fuses, the value read is just used to
> > select one of the OPPs defined in the DT. If you want to attack the
> > system by heavily overclocking or baking it with a high voltage, you can
> > just change the limits in the DT. Not sure if that's easier or harder than
> > accessing the hardware, though.
> 
> I see. Right, my initial comment regarding the ROM content was missing
> the core of the problem.
> 
> > But more importantly, looking at this particular patch: This effectively
> > limits the access size of the value we read from the SID OTP driver, from
> > always 4 bytes to what the DT says, typically 2 bytes. But we actually
> > mask the value in the code anyway later at the moment, so the upper 16
> > bits are always discarded.
> > Which means that as it stands at the moment, there is no real change in
> > what values are used. I just did the change as it was clearly incorrect,
> > and I wanted to prevent any issues, in case of code changes later.
> 
> Ok, thanks for clarifying that in the present form, the code behaves
> the same before and after the fix (the upper 16 bits discarded
> anyway). Your fix improves the code and makes it future-proof.
> 
> Greg:
> 
> given this information, and Andre (developer of the change) saying at the
> beginning of his message that he thinks the bug shouldn't be a CVE, do
> you think the CVE can be revoked?

Now revoked, thanks!

greg k-h