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

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

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

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