Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2340593ybz; Thu, 23 Apr 2020 16:20:35 -0700 (PDT) X-Google-Smtp-Source: APiQypKILoI8a5RAza5cmwVPrTwUpwGSHY2bs6g7hkku60EKA6SumnqPwj7LIJ7r7PN/Lw5uDFSj X-Received: by 2002:a05:6402:752:: with SMTP id p18mr5127583edy.261.1587684035167; Thu, 23 Apr 2020 16:20:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587684035; cv=none; d=google.com; s=arc-20160816; b=segm78ZuWImdLMKE/FoSNmN6UfXMD7lRvey56P47WD+5AxNk/y3gjlqe3nP/LQYiPl gNcj+/0iGhlRSy/b6LIXbvq/G+S8YGkTFydjWu68VrRO9+qzv7FegzKnuDGbtGaFX9Hk /6NXmKMqaLAxyPemQoyl/MKBLnGPV1NekKbyiPtEefJkvw/Qgtzf4KUN2hXv4CIu6lUa HwsZkN4/7EyQM4z9+KjNY3IOl7NG/90L4blbRSa6egoSle5ELisGywemXnnGpdWMlwEM o4yEFE9pT92M4+U1T99ul5OUs048xhK1uw1b1dQ4lJcBFI1Fx1eOaXR2bAMTtqYeWcRP PyOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=afA0CCKebucxsA4iVggqCtqJ6tn4l5fr/sxrYrRDeg8=; b=bzwS2lnwRlxva+R0DTkrEDu9tseosu8gjYJ8zEnMFpYwWLcSRx2hZKcn7qHeNI5WEr /yIA9ZA6gWqWmH2KIRjZMg1+hVpfV6/ZmPWAHFHZBz6y+grmjqkbeIrFUi3uxInMM8Nr wX+AyoEDJBdQCNBixOnSlje5y+P14KcGvPJJoeU7AH2uT/Tm3GGYwyGK1WgfOod0l+xl tm4FoQ3nkOvMjBMT5ilBDGxWe7lklKKodlN+hhJTG6Nc/CroyKv6OWyrtosHTO4/PT8s c6o6vzpQiYonKRsUIesYZMMESMZvFb2wnfzfsGccXDlrdpTwr+cBB7Kl50Y0ykZWPC5u 48Ng== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g24si1967286ejb.433.2020.04.23.16.20.10; Thu, 23 Apr 2020 16:20:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728845AbgDWXQO (ORCPT + 99 others); Thu, 23 Apr 2020 19:16:14 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:49572 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728390AbgDWXGq (ORCPT ); Thu, 23 Apr 2020 19:06:46 -0400 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jRkvS-0004hY-Ra; Fri, 24 Apr 2020 00:06:35 +0100 Received: from ben by deadeye with local (Exim 4.93) (envelope-from ) id 1jRkvS-00E6rA-DH; Fri, 24 Apr 2020 00:06:34 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, Denis Kirjanov , "Pengcheng Yang" , "Eric Dumazet" , "David S. Miller" Date: Fri, 24 Apr 2020 00:06:18 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 151/245] tcp: fix "old stuff" D-SACK causing SACK to be treated as D-SACK In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.83-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Pengcheng Yang commit c9655008e7845bcfdaac10a1ed8554ec167aea88 upstream. When we receive a D-SACK, where the sequence number satisfies: undo_marker <= start_seq < end_seq <= prior_snd_una we consider this is a valid D-SACK and tcp_is_sackblock_valid() returns true, then this D-SACK is discarded as "old stuff", but the variable first_sack_index is not marked as negative in tcp_sacktag_write_queue(). If this D-SACK also carries a SACK that needs to be processed (for example, the previous SACK segment was lost), this SACK will be treated as a D-SACK in the following processing of tcp_sacktag_write_queue(), which will eventually lead to incorrect updates of undo_retrans and reordering. Fixes: fd6dad616d4f ("[TCP]: Earlier SACK block verification & simplify access to them") Signed-off-by: Pengcheng Yang Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- net/ipv4/tcp_input.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -1713,8 +1713,11 @@ tcp_sacktag_write_queue(struct sock *sk, } /* Ignore very old stuff early */ - if (!after(sp[used_sacks].end_seq, prior_snd_una)) + if (!after(sp[used_sacks].end_seq, prior_snd_una)) { + if (i == 0) + first_sack_index = -1; continue; + } used_sacks++; }