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: <805e1a14-7f07-47f0-ba86-f326e4ecea01@suse.com>
Date: Fri, 30 May 2025 20:00:37 +0200
From: Giovanni Gherdovich <giovanni.gherdovich@...e.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: 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>,
 Andre Przywara <andre.przywara@....com>
Subject: Re: CVE-2025-37832: cpufreq: sun50i: prevent out-of-bounds access

On Fri May 30, 2025 16:15, Greg KH wrote:
> 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.

Thanks for clarifying this aspect. I'll move to a different objection,
which is that the incorrect power management configuration that may
result from this bug doesn't constitute a security vulnerability.
It seems to me the CPU won't run at the intended clock, which is
definitely a bug but not a CVE.

I'm CC'ing the change author and the subsystem maintainers to hear their
opinion.

> 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 :(

Sure, you're right, I forgot to include them, fixed now.

Yangtao Li, Rafael, Viresh, Andre:
I'm asking Greg and the kernel CNA to reconsider the assignment of CVE
status to the bug fixed by 14c8a418159e541d70dbf8fc71225d1623beaf0f
("cpufreq: sun50i: prevent out-of-bounds access").
You can find the CVE announcement email at
https://lore.kernel.org/linux-cve-announce/2025050824-CVE-2025-37832-e235@gregkh/

If any of you thinks the status of CVE is well justified in this case,
I'd appreciated if you could reply here, so I can make a mental note
for similar future cases.

Thanks,
Giovanni