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>

1 files changed, 7 insertions, 4 deletions

diff --git a/src/or/scheduler_kist.c b/src/or/scheduler_kist.c
index 3d8f553ac2..9acd89b37f 100644
--- a/src/or/scheduler_kist.c
+++ b/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;
   }