sched: Avoid integer overflow when computing tcp_space

In KIST, we could have a small congestion window value than the unacked
packets leading to a integer overflow which leaves the tcp_space value to be
humongous.

This has no security implications but it results in KIST scheduler allowing to
send cells on a potentially saturated connection.

Found by #24423. Fixes #24590.

Signed-off-by: David Goulet <dgoulet@torproject.org>

changes/bug24590

@@ -0,0 +1,5 @@
+  o Minor bugfixes (scheduler, KIST):
+    - Avoid a possible integer overflow when computing the available space on
+      the TCP buffer of a channel. This has no security implications but can
+      make KIST not behave properly by allowing more cells on a already
+      saturated connection. Fixes bug 24590; bugfix on 0.3.2.1-alpha.

src/or/scheduler_kist.c

@@ -264,10 +264,13 @@ update_socket_info_impl, (socket_table_ent_t *ent))
    *                                         ^ ((cwnd * mss) * factor) bytes
    */
 
-   /* Assuming all these values from the kernel are uint32_t still, they will
-   * always fit into a int64_t tcp_space variable. */
-  tcp_space = (ent->cwnd - ent->unacked) * (int64_t)ent->mss;
-  if (tcp_space < 0) {
+  /* These values from the kernel are uint32_t, they will always fit into a
+   * int64_t tcp_space variable but if the congestion window cwnd is smaller
+   * than the unacked packets, the remaining TCP space is set to 0 so we don't
+   * write more on this channel. */
+  if (ent->cwnd >= ent->unacked) {
+    tcp_space = (ent->cwnd - ent->unacked) * (int64_t)(ent->mss);
+  } else {
     tcp_space = 0;
   }