Blame dhcp-interval.patch
|
 |
e83fb19 |
diff -up dhcp-4.3.0a1/common/dispatch.c.interval dhcp-4.3.0a1/common/dispatch.c
|
|
|
e83fb19 |
--- dhcp-4.3.0a1/common/dispatch.c.interval 2013-12-20 13:51:14.385260622 +0100
|
|
|
e83fb19 |
+++ dhcp-4.3.0a1/common/dispatch.c 2013-12-20 13:51:14.493259116 +0100
|
|
|
e83fb19 |
@@ -343,7 +343,20 @@ void add_timeout (when, where, what, ref
|
|
|
bd413ec |
q->next = timeouts;
|
|
|
bd413ec |
timeouts = q;
|
|
|
bd413ec |
|
|
|
bd413ec |
- isc_interval_set(&interval, sec & DHCP_SEC_MAX, usec * 1000);
|
|
|
bd413ec |
+ /* isc_time_nowplusinterval() is not safe with 64-bit time_t and will
|
|
|
bd413ec |
+ * return an error for sufficiently large intervals. We have to limit
|
|
|
bd413ec |
+ * the interval to INT_MAX or less to ensure the interval doesn't
|
|
|
bd413ec |
+ * overflow 32 bits, since the returned isc_time_t fields are
|
|
|
bd413ec |
+ * 32-bit unsigned ints.
|
|
|
bd413ec |
+ *
|
|
|
bd413ec |
+ * HACK: The 9 is a magic number of seconds, since some time may have
|
|
|
bd413ec |
+ * gone by since the last call to gettimeofday() and the one in
|
|
|
bd413ec |
+ * isc_time_nowplusinterval().
|
|
|
bd413ec |
+ */
|
|
|
bd413ec |
+ if (sec > TIME_MAX)
|
|
|
bd413ec |
+ sec = TIME_MAX - 9;
|
|
|
bd413ec |
+
|
|
|
bd413ec |
+ isc_interval_set(&interval, sec, usec * 1000);
|
|
|
bd413ec |
status = isc_time_nowplusinterval(&expires, &interval);
|
|
|
bd413ec |
if (status != ISC_R_SUCCESS) {
|
|
|
bd413ec |
/*
|