From patchwork Thu Sep 17 21:07:24 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Abeni X-Patchwork-Id: 1366446 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.01.org (client-ip=2001:19d0:306:5::1; helo=ml01.01.org; envelope-from=mptcp-bounces@lists.01.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=WwyrrSsR; dkim-atps=neutral Received: from ml01.01.org (ml01.01.org [IPv6:2001:19d0:306:5::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4BsqLR2cknz9sSf for ; Fri, 18 Sep 2020 07:07:58 +1000 (AEST) Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id C6BD7148D8E40; Thu, 17 Sep 2020 14:07:53 -0700 (PDT) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=207.211.31.81; helo=us-smtp-delivery-1.mimecast.com; envelope-from=pabeni@redhat.com; receiver= Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 5B6F614FEABBF for ; Thu, 17 Sep 2020 14:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1600376870; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=ii5RKHT4DzfpRC0mW241XcBwMg3usk+atg6kYC/FXIA=; b=WwyrrSsRds3HcPc5InFUmrbqfvwuz/g6PEpD6oHbnQBU1zNG02AmxOx31Iyau7AiWRaZCI gpMxSmK4l2WXG3B7SXpzeSJD094MPiB52p99462VN0XXPHUNao4aD50XnF7G/dE265P845 XtFQb+ZgGQvm5B8R2C+MBPJqDhHqbYI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-257-Wh0TSqGvOwWi6wDxsr31pA-1; Thu, 17 Sep 2020 17:07:47 -0400 X-MC-Unique: Wh0TSqGvOwWi6wDxsr31pA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A8FEE87147F; Thu, 17 Sep 2020 21:07:45 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-112-68.ams2.redhat.com [10.36.112.68]) by smtp.corp.redhat.com (Postfix) with ESMTP id E102E55768; Thu, 17 Sep 2020 21:07:43 +0000 (UTC) From: Paolo Abeni To: netdev@vger.kernel.org Date: Thu, 17 Sep 2020 23:07:24 +0200 Message-Id: <1a927c595adf46cf5ff186ca6b129f12fb70f492.1600375771.git.pabeni@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Message-ID-Hash: 7MRRWT4PJD4EVLERF24UQXTVQXERBNME X-Message-ID-Hash: 7MRRWT4PJD4EVLERF24UQXTVQXERBNME X-MailFrom: pabeni@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: "David S. Miller" , mptcp@lists.01.org X-Mailman-Version: 3.1.1 Precedence: list Subject: [MPTCP] [PATCH net-next] mptcp: fix integer overflow in mptcp_subflow_discard_data() List-Id: Discussions regarding MPTCP upstreaming Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: 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 Signed-off-by: Paolo Abeni Reviewed-by: Mat Martineau --- net-next patch, as the culprit commit is only on net-next currently --- net/mptcp/subflow.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index a2ae3087e24d..34d6230df017 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -807,7 +807,7 @@ static enum mapping_status get_mapping_status(struct sock *ssk, } static void mptcp_subflow_discard_data(struct sock *ssk, struct sk_buff *skb, - unsigned int limit) + u64 limit) { struct mptcp_subflow_context *subflow = mptcp_subflow_ctx(ssk); bool fin = TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN;