Bugzilla – Bug 963761
VUL-0: CVE-2016-2070: kernel: potential division by zero in TCP code
Last modified: 2016-08-31 12:20:07 UTC
From: Florian Weimer While looking for something else entirely, I came across this commit, initially reported at <https://lkml.org/lkml/2015/12/21/435>: commit 8b8a321ff72c785ed5e8b4cf6eda20b35d427390 Author: Yuchung Cheng <ycheng () google com> Date: Wed Jan 6 12:42:38 2016 -0800 tcp: fix zero cwnd in tcp_cwnd_reduction Patch 3759824da87b ("tcp: PRR uses CRB mode by default and SS mode conditionally") introduced a bug that cwnd may become 0 when both inflight and sndcnt are 0 (cwnd = inflight + sndcnt). This may lead to a div-by-zero if the connection starts another cwnd reduction phase by setting tp->prior_cwnd to the current cwnd (0) in tcp_init_cwnd_reduction(). To prevent this we skip PRR operation when nothing is acked or sacked. Then cwnd must be positive in all cases as long as ssthresh is positive: 1) The proportional reduction mode inflight > ssthresh > 0 2) The reduction bound mode a) inflight == ssthresh > 0 b) inflight < ssthresh sndcnt > 0 since newly_acked_sacked > 0 and inflight < ssthresh Therefore in all cases inflight and sndcnt can not both be 0. We check invalid tp->prior_cwnd to avoid potential div0 bugs. In reality this bug is triggered only with a sequence of less common events. For example, the connection is terminating an ECN-triggered cwnd reduction with an inflight 0, then it receives reordered/old ACKs or DSACKs from prior transmission (which acks nothing). Or the connection is in fast recovery stage that marks everything lost, but fails to retransmit due to local issues, then receives data packets from other end which acks nothing. References: https://bugzilla.redhat.com/show_bug.cgi?id=1302219 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-2070 http://seclists.org/oss-sec/2016/q1/211 http://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-2070.html
Looks to me like we don't have the code that introduced the problem, but please check it.
According to the commit id's, the bug was introduced in 4.3-rc1 and fixed in 4.4. So unless we backported the first commit into some of our branches (unlikely but I'm going to check), none of our products should be affected.
Commit 3759824da87b hasn't been backported to any of our kernel branches so that there is nothing to fix (Factory is already on 4.4 and thus fixed). Closing and reassigning back to Security team.