]> git.ipfire.org Git - thirdparty/tor.git/commitdiff
Bulletproof the safe_timer_diff function
authorNick Mathewson <nickm@torproject.org>
Fri, 29 Jan 2016 03:04:24 +0000 (22:04 -0500)
committerNick Mathewson <nickm@torproject.org>
Wed, 10 Feb 2016 20:49:11 +0000 (15:49 -0500)
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.

src/or/main.c

index bd4f7eaa71ae8ddc551d603103a8f96a5df8f5b4..30c24e5ca41ab4ef04e5262b57617198b31634d5 100644 (file)
@@ -1414,11 +1414,23 @@ reschedule_directory_downloads(void)
   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
 safe_timer_diff(time_t now, time_t next)
 {
   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);
   } else {
     return 1;