mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH] rtc: tps6594: Fix integer overflow on 32bit systems
@ 2024-12-11  9:32 Dan Carpenter
  2024-12-11 11:51 ` Andy Shevchenko
  2025-01-12 23:21 ` Alexandre Belloni
  0 siblings, 2 replies; 4+ messages in thread
From: Dan Carpenter @ 2024-12-11  9:32 UTC (permalink / raw)
  To: Esteban Blanc
  Cc: Alexandre Belloni, Andy Shevchenko, linux-rtc, linux-kernel,
	kernel-janitors

The problem is this multiply in tps6594_rtc_set_offset()

	tmp = offset * TICKS_PER_HOUR;

The "tmp" variable is an s64 but "offset" is a long in the
(-277774)-277774 range.  On 32bit systems a long can hold numbers up to
approximately two billion.  The number of TICKS_PER_HOUR is really large,
(32768 * 3600) or roughly a hundred million.  When you start multiplying
by a hundred million it doesn't take long to overflow the two billion
mark.

Probably the safest way to fix this is to change the type of
TICKS_PER_HOUR to long long because it's such a large number.

Fixes: 9f67c1e63976 ("rtc: tps6594: Add driver for TPS6594 RTC")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
---
 drivers/rtc/rtc-tps6594.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-tps6594.c b/drivers/rtc/rtc-tps6594.c
index e69667634137..7c6246e3f029 100644
--- a/drivers/rtc/rtc-tps6594.c
+++ b/drivers/rtc/rtc-tps6594.c
@@ -37,7 +37,7 @@
 #define MAX_OFFSET (277774)
 
 // Number of ticks per hour
-#define TICKS_PER_HOUR (32768 * 3600)
+#define TICKS_PER_HOUR (32768 * 3600LL)
 
 // Multiplier for ppb conversions
 #define PPB_MULT NANO
-- 
2.45.2

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] rtc: tps6594: Fix integer overflow on 32bit systems
  2024-12-11  9:32 [PATCH] rtc: tps6594: Fix integer overflow on 32bit systems Dan Carpenter
@ 2024-12-11 11:51 ` Andy Shevchenko
  2024-12-11 12:29   ` Dan Carpenter
  2025-01-12 23:21 ` Alexandre Belloni
  1 sibling, 1 reply; 4+ messages in thread
From: Andy Shevchenko @ 2024-12-11 11:51 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: Esteban Blanc, Alexandre Belloni, linux-rtc, linux-kernel,
	kernel-janitors

On Wed, Dec 11, 2024 at 11:32 AM Dan Carpenter <dan.carpenter@linaro.org> wrote:
>
> The problem is this multiply in tps6594_rtc_set_offset()
>
>         tmp = offset * TICKS_PER_HOUR;
>
> The "tmp" variable is an s64 but "offset" is a long in the
> (-277774)-277774 range.  On 32bit systems a long can hold numbers up to
> approximately two billion.  The number of TICKS_PER_HOUR is really large,
> (32768 * 3600) or roughly a hundred million.  When you start multiplying
> by a hundred million it doesn't take long to overflow the two billion
> mark.
>
> Probably the safest way to fix this is to change the type of
> TICKS_PER_HOUR to long long because it's such a large number.

...

> -#define TICKS_PER_HOUR (32768 * 3600)
> +#define TICKS_PER_HOUR (32768 * 3600LL)

Hmm... And why signed?

Wondering, do we deserve to have something like
#define SEC_PER_HOUR 3600UL
somewhere in the headers, if not already exists?

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] rtc: tps6594: Fix integer overflow on 32bit systems
  2024-12-11 11:51 ` Andy Shevchenko
@ 2024-12-11 12:29   ` Dan Carpenter
  0 siblings, 0 replies; 4+ messages in thread
From: Dan Carpenter @ 2024-12-11 12:29 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Esteban Blanc, Alexandre Belloni, linux-rtc, linux-kernel,
	kernel-janitors

On Wed, Dec 11, 2024 at 01:51:31PM +0200, Andy Shevchenko wrote:
> On Wed, Dec 11, 2024 at 11:32 AM Dan Carpenter <dan.carpenter@linaro.org> wrote:
> >
> > The problem is this multiply in tps6594_rtc_set_offset()
> >
> >         tmp = offset * TICKS_PER_HOUR;
> >
> > The "tmp" variable is an s64 but "offset" is a long in the
> > (-277774)-277774 range.  On 32bit systems a long can hold numbers up to
> > approximately two billion.  The number of TICKS_PER_HOUR is really large,
> > (32768 * 3600) or roughly a hundred million.  When you start multiplying
> > by a hundred million it doesn't take long to overflow the two billion
> > mark.
> >
> > Probably the safest way to fix this is to change the type of
> > TICKS_PER_HOUR to long long because it's such a large number.
> 
> ...
> 
> > -#define TICKS_PER_HOUR (32768 * 3600)
> > +#define TICKS_PER_HOUR (32768 * 3600LL)
> 
> Hmm... And why signed?

It needs to be signed for negatives.  That's deliberate.

regards,
dan carpenter

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] rtc: tps6594: Fix integer overflow on 32bit systems
  2024-12-11  9:32 [PATCH] rtc: tps6594: Fix integer overflow on 32bit systems Dan Carpenter
  2024-12-11 11:51 ` Andy Shevchenko
@ 2025-01-12 23:21 ` Alexandre Belloni
  1 sibling, 0 replies; 4+ messages in thread
From: Alexandre Belloni @ 2025-01-12 23:21 UTC (permalink / raw)
  To: Esteban Blanc, Dan Carpenter
  Cc: Andy Shevchenko, linux-rtc, linux-kernel, kernel-janitors

On Wed, 11 Dec 2024 12:32:34 +0300, Dan Carpenter wrote:
> The problem is this multiply in tps6594_rtc_set_offset()
> 
> 	tmp = offset * TICKS_PER_HOUR;
> 
> The "tmp" variable is an s64 but "offset" is a long in the
> (-277774)-277774 range.  On 32bit systems a long can hold numbers up to
> approximately two billion.  The number of TICKS_PER_HOUR is really large,
> (32768 * 3600) or roughly a hundred million.  When you start multiplying
> by a hundred million it doesn't take long to overflow the two billion
> mark.
> 
> [...]

Applied, thanks!

[1/1] rtc: tps6594: Fix integer overflow on 32bit systems
      https://git.kernel.org/abelloni/c/09c4a6101532

Best regards,

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2025-01-12 23:21 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-12-11  9:32 [PATCH] rtc: tps6594: Fix integer overflow on 32bit systems Dan Carpenter
2024-12-11 11:51 ` Andy Shevchenko
2024-12-11 12:29   ` Dan Carpenter
2025-01-12 23:21 ` Alexandre Belloni

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®