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

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

[Giovanni Gherdovich]

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.

I don't think this qualifies as vulnerability.

Giovanni

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

[Greg KH]

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,

greg k-h

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

[Greg KH]

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

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

[Giovanni Gherdovich]

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

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

[Andre Przywara]

On Fri, 30 May 2025 20:00:37 +0200
Giovanni Gherdovich <giovanni.gherdovich@suse.com> 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 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.

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.

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.

Hope that helps!

Cheers,
Andre

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

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

[Giovanni Gherdovich]

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?


Thanks,
Giovanni

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

[Greg KH]

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