summaryrefslogtreecommitdiff
path: root/security
diff options
context:
space:
mode:
authorPaolo Abeni <pabeni@redhat.com>2020-09-18 00:07:24 +0300
committerDavid S. Miller <davem@davemloft.net>2020-09-18 04:04:48 +0300
commit1d39cd8cf75f79d082ee97f5fd2a6286bcc692c1 (patch)
tree8e34c2405e96264b021eb296b27a805838c5b690 /security
parentac679364b98edb4ba46a482c7ab52e2ccb82b8de (diff)
downloadlinux-1d39cd8cf75f79d082ee97f5fd2a6286bcc692c1.tar.xz
mptcp: fix integer overflow in mptcp_subflow_discard_data()
Christoph reported an infinite loop in the subflow receive path under stress condition. If there are multiple subflows, each of them using a large send buffer, the delta between the sequence number used by MPTCP-level retransmission can and the current msk->ack_seq can be greater than MAX_INT. In the above scenario, when calling mptcp_subflow_discard_data(), such delta will be truncated to int, and could result in a negative number: no bytes will be dropped, and subflow_check_data_avail() will try again to process the same packet, looping forever. This change addresses the issue by expanding the 'limit' size to 64 bits, so that overflows are not possible anymore. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/87 Fixes: 6719331c2f73 ("mptcp: trigger msk processing even for OoO data") Reported-and-tested-by: Christoph Paasch <cpaasch@apple.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'security')
0 files changed, 0 insertions, 0 deletions