From patchwork Wed Dec 2 16:12:15 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Abeni X-Patchwork-Id: 1409810 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=198.145.21.10; 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=RfYGbTCl; dkim-atps=neutral Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4CmPBm2NSYz9sSf for ; Thu, 3 Dec 2020 03:12:48 +1100 (AEDT) Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 385A4100EBB62; Wed, 2 Dec 2020 08:12:46 -0800 (PST) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=216.205.24.124; helo=us-smtp-delivery-124.mimecast.com; envelope-from=pabeni@redhat.com; receiver= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 82ACC100EBBDF for ; Wed, 2 Dec 2020 08:12:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1606925562; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Tz8Mbd/nUzK2VY+A6HSLRkcP4n8rs1UoQYHf9v37hLI=; b=RfYGbTClCpAlHvpL+adnCIiJnAm/6nAGUguA43IEwyFcirWpPbdda/0z31ZMgugLjfVJT7 l6dp6TUAgsdoLd1RMJP9v0iQFXuUmHdXBz8WJ5T7gTeKQFYwznExasKeZuK3DYAFrvOs5P 9ikL2n24enlhQZyCA8F15okiHD0Q1Rs= 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-173-5GJ3WgtMOuyUnYFIRQexzg-1; Wed, 02 Dec 2020 11:12:39 -0500 X-MC-Unique: 5GJ3WgtMOuyUnYFIRQexzg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A1BF056FDE for ; Wed, 2 Dec 2020 16:12:38 +0000 (UTC) Received: from gerbillo.redhat.com (ovpn-112-254.ams2.redhat.com [10.36.112.254]) by smtp.corp.redhat.com (Postfix) with ESMTP id DC5A919D7C for ; Wed, 2 Dec 2020 16:12:37 +0000 (UTC) From: Paolo Abeni To: mptcp@lists.01.org Date: Wed, 2 Dec 2020 17:12:15 +0100 Message-Id: <7cc29abe8da61eeb3e6c7bd5d2d8fe1d51dcdd7e.1606924518.git.pabeni@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=pabeni@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Message-ID-Hash: 5J6AXODETJCNA6LMYWF2H44Y27K3HX2L X-Message-ID-Hash: 5J6AXODETJCNA6LMYWF2H44Y27K3HX2L 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 X-Mailman-Version: 3.1.1 Precedence: list Subject: [MPTCP] [PATCH mptcp-next] mptcp: address potential infinite loop on receive List-Id: Discussions regarding MPTCP upstreaming Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Eric noted the MPTCP recvmsg() loop can iterate multiple times when the argument lenght is 0 and some subflow is feeding new data. Be sure to quite the loop soon moving the exit condition earlier. Additionally move a related comment into the right place. Reported-by: Eric Dumazet Fixes: ea4ca586b16f ("mptcp: refine MPTCP-level ack scheduling") Signed-off-by: Paolo Abeni --- Note: looking again at the current code, I think that at worst we can do a single additional, unneeded iteration - after the first 'continue' statement __mptcp_move_skbs() will have moved some data into the receive_queue, and we are not going to receive them. On next iteration the receive_queue will be not empty. Unless the peer is crafting some malicious DSS/packets combo I'm unable to foreseen. --- net/mptcp/protocol.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 221f7cdd416b..5a3f4bc38ee3 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -1933,21 +1933,21 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len, copied += bytes_read; - if (skb_queue_empty(&msk->receive_queue) && - __mptcp_move_skbs(msk, len - copied)) - continue; - /* be sure to advertise window change */ old_space = READ_ONCE(msk->old_wspace); if ((tcp_space(sk) - old_space) >= old_space) mptcp_cleanup_rbuf(msk); - /* only the master socket status is relevant here. The exit - * conditions mirror closely tcp_recvmsg() - */ if (copied >= target) break; + if (skb_queue_empty(&msk->receive_queue) && + __mptcp_move_skbs(msk, len - copied)) + continue; + + /* only the master socket status is relevant here. The exit + * conditions mirror closely tcp_recvmsg() + */ if (copied) { if (sk->sk_err || sk->sk_state == TCP_CLOSE ||