Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2978690ybk; Mon, 18 May 2020 12:38:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzCH0BKY+bmnz2HURerzSmhcCgi+37mCVI/10DcUgl9BMZEm21HPVKu49OKswVz3MlopJV+ X-Received: by 2002:a50:c889:: with SMTP id d9mr15250545edh.81.1589830738192; Mon, 18 May 2020 12:38:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589830738; cv=none; d=google.com; s=arc-20160816; b=pbbpyXyQjjSoe1w2Vs9xc3K6mZYMLgINRHAOGDzVqJH09eMpcqQypO+otU2WqMJujk BiWSDVYNpipcq3VgpQd8Rd2PKYrxQ1w4A8ikYq+HqYWO4rLCD4Rd+NExTI1QhcdJFSDm JlSNvaUCN/A5ntsaEOyKoshWERLrslGL7SuRxUt0QR4M5rQQebHKNuxxZgRYJV4uee6a xR9ukv1RGzMPkOfsNbbk6OKbth4GI93S2mLCnfUhexKsQCIh0ipBtNNTzfDFtTw4OXRH 4RsuRvsp0EqBlqU69/Wzrmrl64B/8sasLRroOZcyShj2RnRmqjHZFwwrhOLSsbFu1rLc to7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=b9hNXGPzuLpkZh8pFaso24nH9FOBnOTKCjYSNZUKOi8=; b=WpoLgva7tQ83+8WocoJKxCzsTQOYGcC401JJs9i7/MiFWTQ9nmrrvatFvRfoIV8Hsa UYyvzWkBHmIPzq0Xfmuexbnul54v9mJ9BmaWCO223uH6co5Vu77z7AShn5J2RYQbwLlt 8lfLjAmwe1KnuTp1YZWfbTcMQf7PMK/XCD3xPdhsgszCwhpDBDTmJAqyOrxBma7yOF7O x9BbFcOin5fUs7ZbgznQLnkdy/8REYHiFTmVV+ABEPg/fo5ACyfDVBzSxoFP5Zn5rnn3 E9GIMxadSMuWW49jEKJtlO+movgiAv0BvFYoIVgEYs6KZRIc5O9N10p/XN++kqSlC2gd +k2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=SEjHOZj8; 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 g6si6595237ejc.326.2020.05.18.12.38.34; Mon, 18 May 2020 12:38:58 -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; dkim=pass header.i=@kernel.org header.s=default header.b=SEjHOZj8; 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 S1732069AbgERSDM (ORCPT + 99 others); Mon, 18 May 2020 14:03:12 -0400 Received: from mail.kernel.org ([198.145.29.99]:48130 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732600AbgERSDE (ORCPT ); Mon, 18 May 2020 14:03:04 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DAFC6207D3; Mon, 18 May 2020 18:03:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1589824983; bh=tehWF7fpkndSMrdZ/mvh2Ukdq+BeAudbWlSRcul9Fdg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SEjHOZj80DggZ1usXq9144RvPp11wEHDbwRH8OvkM1ZtRDWJAGB2s0cYqoawQLfnr mBoATwBujsiEOvUKoauqQbqkmudcDQNgfqT2np27gbstR5z+QefMtqISy29gYxnjmr jumjAKAMBT0W6OgtNordkxcELlYsvW5i7uW8zui0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Paolo Abeni , Jakub Kicinski , Colin Walters Subject: [PATCH 5.6 044/194] net: ipv4: really enforce backoff for redirects Date: Mon, 18 May 2020 19:35:34 +0200 Message-Id: <20200518173535.436284069@linuxfoundation.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200518173531.455604187@linuxfoundation.org> References: <20200518173531.455604187@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Paolo Abeni [ Upstream commit 57644431a6c2faac5d754ebd35780cf43a531b1a ] In commit b406472b5ad7 ("net: ipv4: avoid mixed n_redirects and rate_tokens usage") I missed the fact that a 0 'rate_tokens' will bypass the backoff algorithm. Since rate_tokens is cleared after a redirect silence, and never incremented on redirects, if the host keeps receiving packets requiring redirect it will reply ignoring the backoff. Additionally, the 'rate_last' field will be updated with the cadence of the ingress packet requiring redirect. If that rate is high enough, that will prevent the host from generating any other kind of ICMP messages The check for a zero 'rate_tokens' value was likely a shortcut to avoid the more complex backoff algorithm after a redirect silence period. Address the issue checking for 'n_redirects' instead, which is incremented on successful redirect, and does not interfere with other ICMP replies. Fixes: b406472b5ad7 ("net: ipv4: avoid mixed n_redirects and rate_tokens usage") Reported-and-tested-by: Colin Walters Signed-off-by: Paolo Abeni Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman --- net/ipv4/route.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -915,7 +915,7 @@ void ip_rt_send_redirect(struct sk_buff /* Check for load limit; set rate_last to the latest sent * redirect. */ - if (peer->rate_tokens == 0 || + if (peer->n_redirects == 0 || time_after(jiffies, (peer->rate_last + (ip_rt_redirect_load << peer->n_redirects)))) {