| Message ID | 1074175e-5ecb-4e3d-b721-347d794caa90@stanley.mountain |
|---|---|
| State | Accepted |
| Headers | show |
| Series | rtc: tps6594: Fix integer overflow on 32bit systems | expand |
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?
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
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,
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
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(-)