ACPI: LPIT: fix u32 multiplication overflow

In lpit_update_residency there is a possibility of overflow
in multiplication, if tsc_khz is large enough (> UINT_MAX/1000).

Change multiplication to mul_u32_u32.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: eeb2d80d502a ("ACPI / LPIT: Add Low Power Idle Table (LPIT) support")
Signed-off-by: Nikita Kiryushin <kiryushin@ancud.ru>
---
  drivers/acpi/acpi_lpit.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

On Thu, Nov 9, 2023 at 7:09 PM Nikita Kiryushin <kiryushin@ancud.ru> wrote:
>
> In lpit_update_residency there is a possibility of overflow
> in multiplication, if tsc_khz is large enough (> UINT_MAX/1000).

That would be a TSC ticking at hundreds of millions of kHz if I'm not
mistaken.  Why is it really a concern?

> Change multiplication to mul_u32_u32.

So why is this better?

> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>
> Fixes: eeb2d80d502a ("ACPI / LPIT: Add Low Power Idle Table (LPIT) support")
> Signed-off-by: Nikita Kiryushin <kiryushin@ancud.ru>
> ---
>   drivers/acpi/acpi_lpit.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/acpi_lpit.c b/drivers/acpi/acpi_lpit.c
> index c5598b6d5db8..794962c5c88e 100644
> --- a/drivers/acpi/acpi_lpit.c
> +++ b/drivers/acpi/acpi_lpit.c
> @@ -105,7 +105,7 @@ static void lpit_update_residency(struct
> lpit_residency_info *info,
>                 return;
>         info->frequency = lpit_native->counter_frequency ?
> -                               lpit_native->counter_frequency : tsc_khz * 1000;
> +                               lpit_native->counter_frequency : mul_u32_u32(tsc_khz, 1000U);
>         if (!info->frequency)
>                 info->frequency = 1;
>   -- 2.34.1
>

On Tue, Nov 21, 2023 at 8:56 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Thu, Nov 9, 2023 at 7:09 PM Nikita Kiryushin <kiryushin@ancud.ru> wrote:
> >
> > In lpit_update_residency there is a possibility of overflow
> > in multiplication, if tsc_khz is large enough (> UINT_MAX/1000).
>
> That would be a TSC ticking at hundreds of millions of kHz if I'm not
> mistaken.

That should be "hundreds of thousands of kHz", so I was mistaken.

But anyway:

> Why is it really a concern?
>
> > Change multiplication to mul_u32_u32.
>
> So why is this better?
>
> > Found by Linux Verification Center (linuxtesting.org) with SVACE.
> >
> > Fixes: eeb2d80d502a ("ACPI / LPIT: Add Low Power Idle Table (LPIT) support")
> > Signed-off-by: Nikita Kiryushin <kiryushin@ancud.ru>
> > ---
> >   drivers/acpi/acpi_lpit.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/acpi/acpi_lpit.c b/drivers/acpi/acpi_lpit.c
> > index c5598b6d5db8..794962c5c88e 100644
> > --- a/drivers/acpi/acpi_lpit.c
> > +++ b/drivers/acpi/acpi_lpit.c
> > @@ -105,7 +105,7 @@ static void lpit_update_residency(struct
> > lpit_residency_info *info,
> >                 return;
> >         info->frequency = lpit_native->counter_frequency ?
> > -                               lpit_native->counter_frequency : tsc_khz * 1000;
> > +                               lpit_native->counter_frequency : mul_u32_u32(tsc_khz, 1000U);
> >         if (!info->frequency)
> >                 info->frequency = 1;
> >   -- 2.34.1
> >

My reasoning was around something like:

1) tsc_khz is declared as unsigned int tsc_khz;

2) tsc_khz * 1000 would overflow, if the result is larger, than an 
unsigned int could hold;

3) given tsc_khz * 1000 > UINT_MAX is bad, tsc_khz > UINT_MAX / 1000 is bad;

4) if UINT_MAX is 4294967295, than tsc_khz > 4294967.295 is bad, for 
example 4294968 would lead to overflow;

5) 4294968 kHz is 4294.968 MHz, which seems realistically high to me.

For me, tsc: Refined TSC clocksource calibration: 3393.624 MHz

(seems like, it is derived from the same value,

pr_info("Refined TSC clocksource calibration: %lu.%03lu MHz\n",
         (unsigned long)tsc_khz / 1000,
         (unsigned long)tsc_khz % 1000);

)

Not sure about the math above, but it seemed reasonable enough to me to 
switch to overflow-resilient arithmetic here.


On 11/21/23 23:14, Rafael J. Wysocki wrote:
> On Tue, Nov 21, 2023 at 8:56 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> That should be "hundreds of thousands of kHz", so I was mistaken.
>
> But anyway:
>
>> Why is it really a concern?
>>

On Wed, Nov 22, 2023 at 8:41 PM Nikita Kiryushin <kiryushin@ancud.ru> wrote:
>
> My reasoning was around something like:
>
> 1) tsc_khz is declared as unsigned int tsc_khz;
>
> 2) tsc_khz * 1000 would overflow, if the result is larger, than an
> unsigned int could hold;
>
> 3) given tsc_khz * 1000 > UINT_MAX is bad, tsc_khz > UINT_MAX / 1000 is bad;
>
> 4) if UINT_MAX is 4294967295, than tsc_khz > 4294967.295 is bad, for
> example 4294968 would lead to overflow;
>
> 5) 4294968 kHz is 4294.968 MHz, which seems realistically high to me.
>
> For me, tsc: Refined TSC clocksource calibration: 3393.624 MHz
>
> (seems like, it is derived from the same value,
>
> pr_info("Refined TSC clocksource calibration: %lu.%03lu MHz\n",
>          (unsigned long)tsc_khz / 1000,
>          (unsigned long)tsc_khz % 1000);
>
> )

OK, fair enough.

> Not sure about the math above, but it seemed reasonable enough to me to
> switch to overflow-resilient arithmetic here.