[tor-commits] [tor/master] Bulletproof the safe_timer_diff function

[nickm@xxxxxxxxxxxxxx]

commit 601b41084af1f941c4266237e2c6df46be8981dd
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
Date:   Thu Jan 28 22:04:24 2016 -0500

    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.
---
 src/or/main.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/src/or/main.c b/src/or/main.c
index bd4f7ea..30c24e5 100644
--- a/src/or/main.c
+++ b/src/or/main.c
@@ -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;



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits