mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-28 06:13:31 +01:00
Bulletproof the safe_timer_diff function
Originally it can overflow in some weird cases. Now it should no longer be able to do so. Additionally, limit main's timers to 30 days rather than to 38 years; we don't actually want any 38-year timers. Closes bug 17682.
This commit is contained in:
parent
a5bed4dab2
commit
601b41084a
@ -1414,11 +1414,23 @@ reschedule_directory_downloads(void)
|
|||||||
periodic_event_reschedule(launch_descriptor_fetches_event);
|
periodic_event_reschedule(launch_descriptor_fetches_event);
|
||||||
}
|
}
|
||||||
|
|
||||||
|
#define LONGEST_TIMER_PERIOD (30 * 86400)
|
||||||
|
/** Helper: Return the number of seconds between <b>now</b> and <b>next</b>,
|
||||||
|
* clipped to the range [1 second, LONGEST_TIMER_PERIOD]. */
|
||||||
static inline int
|
static inline int
|
||||||
safe_timer_diff(time_t now, time_t next)
|
safe_timer_diff(time_t now, time_t next)
|
||||||
{
|
{
|
||||||
if (next > now) {
|
if (next > now) {
|
||||||
tor_assert(next - now <= INT_MAX);
|
/* There were no computers at signed TIME_MIN (1902 on 32-bit systems),
|
||||||
|
* and nothing that could run Tor. It's a bug if 'next' is around then.
|
||||||
|
* On 64-bit systems with signed TIME_MIN, TIME_MIN is before the Big
|
||||||
|
* Bang. We cannot extrapolate past a singularity, but there was probably
|
||||||
|
* nothing that could run Tor then, either.
|
||||||
|
**/
|
||||||
|
tor_assert(next > TIME_MIN + LONGEST_TIMER_PERIOD);
|
||||||
|
|
||||||
|
if (next - LONGEST_TIMER_PERIOD > now)
|
||||||
|
return LONGEST_TIMER_PERIOD;
|
||||||
return (int)(next - now);
|
return (int)(next - now);
|
||||||
} else {
|
} else {
|
||||||
return 1;
|
return 1;
|
||||||
|
Loading…
Reference in New Issue
Block a user