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

Message-ID: <2025053010-legible-destiny-23d3@gregkh>
Date: Fri, 30 May 2025 16:15:50 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Giovanni Gherdovich <giovanni.gherdovich@...e.com>
Cc: cve@...nel.org, linux-kernel@...r.kernel.org,
	linux-cve-announce@...r.kernel.org
Subject: Re: CVE-2025-37832: cpufreq: sun50i: prevent out-of-bounds access

On Fri, May 30, 2025 at 04:14:51PM +0200, Greg KH wrote:
> 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.
> > 
> > Even assuming that improper frequency/voltage settings constitute a
> > security risk, writing to the ROM in question is at least a privileged
> > operation, and may require physical access to the SoC.
> 
> Obviously there are systems out there that have this issue, with device
> trees that can trigger this issue, this isn't a matter of "malicious ROM
> doing bad things" type of issue, it's a "the DT can't express this
> properly, so we might have taken data from the hardware and handled it
> in the wrong way" type of issue.
> 
> > I don't think this qualifies as vulnerability.
> 
> I don't see how this is a ROM configuration issue, but rather just a
> kernel bug in how the hardware is accessed on different types of systems
> where we previously could not handle such accesses correctly.

Note, if the maintainer or the developer of the change in question here
disagrees with me, great, we'll be glad to revoke this CVE, as we defer
to them.  But for some reason you didn't include them in this thread :(

thanks,

greg k-h