From d944f1d89db89ab473a7df8363e2339dfd8f2411 Mon Sep 17 00:00:00 2001 From: Vadim Yanitskiy Date: Wed, 11 Mar 2020 03:00:22 +0700 Subject: trxcon/scheduler: be safe against a theoretical integer overflow As was noted by Pau Espin Pedrol, there is a theoretical chance that lchan->tdma.num_proc would overflow, so as a consequence, subst_frame_loss() will be unable to compensate one (potentionally lost) Downlink burst. On practice, given the size of unsigned long and duration of a single TDMA frame, it would only happen once in roughly ~6 years. FRAME_DURATION = 4615 * 10e-6 ULONG_MAX = 2 ** 32 - 1 FRAME_DURATION * ULONG_MAX -> ~198212740 seconds -> ~55059 hours -> ~2294 days -> ~6 years. Chances are that trxcon would crash much earlier, or even GSM would be completely forgotten after such a long time run, but let's work this around and simply start counting from 1 if that overflow eventually happens. Change-Id: I3d40ef09b06039a85df52af06ab38de314e1a434 --- src/host/trxcon/sched_trx.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/src/host/trxcon/sched_trx.c b/src/host/trxcon/sched_trx.c index 1efae247..b53b0e83 100644 --- a/src/host/trxcon/sched_trx.c +++ b/src/host/trxcon/sched_trx.c @@ -721,7 +721,16 @@ int sched_trx_handle_rx_burst(struct trx_instance *trx, uint8_t tn, /* Update TDMA frame statistics */ lchan->tdma.last_proc = fn; - lchan->tdma.num_proc++; + + if (++lchan->tdma.num_proc == 0) { + /* Theoretically, we may have an integer overflow of num_proc counter. + * As a consequence, subst_frame_loss() will be unable to compensate + * one (potentionally lost) Downlink burst. On practice, it would + * happen once in 4615 * 10e-6 * (2 ^ 32 - 1) seconds or ~6 years. */ + LOGP(DSCHD, LOGL_NOTICE, "Too many TDMA frames have been processed. " + "Are you running trxcon for more than 6 years?!?\n"); + lchan->tdma.num_proc = 1; + } return 0; } -- cgit v1.2.3