From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org,
Lorenzo Bianconi <lorenzo.bianconi@redhat.com>,
"David S. Miller" <davem@davemloft.net>
Subject: [PATCH 3.18 08/13] net: ipv4: use a dedicated counter for icmp_v4 redirect packets
Date: Thu, 21 Feb 2019 15:35:39 +0100 [thread overview]
Message-ID: <20190221125240.937496983@linuxfoundation.org> (raw)
In-Reply-To: <20190221125240.091472334@linuxfoundation.org>
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
[ Upstream commit c09551c6ff7fe16a79a42133bcecba5fc2fc3291 ]
According to the algorithm described in the comment block at the
beginning of ip_rt_send_redirect, the host should try to send
'ip_rt_redirect_number' ICMP redirect packets with an exponential
backoff and then stop sending them at all assuming that the destination
ignores redirects.
If the device has previously sent some ICMP error packets that are
rate-limited (e.g TTL expired) and continues to receive traffic,
the redirect packets will never be transmitted. This happens since
peer->rate_tokens will be typically greater than 'ip_rt_redirect_number'
and so it will never be reset even if the redirect silence timeout
(ip_rt_redirect_silence) has elapsed without receiving any packet
requiring redirects.
Fix it by using a dedicated counter for the number of ICMP redirect
packets that has been sent by the host
I have not been able to identify a given commit that introduced the
issue since ip_rt_send_redirect implements the same rate-limiting
algorithm from commit 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/net/inetpeer.h | 1 +
net/ipv4/inetpeer.c | 1 +
net/ipv4/route.c | 7 +++++--
3 files changed, 7 insertions(+), 2 deletions(-)
--- a/include/net/inetpeer.h
+++ b/include/net/inetpeer.h
@@ -35,6 +35,7 @@ struct inet_peer {
u32 metrics[RTAX_MAX];
u32 rate_tokens; /* rate limiting for ICMP */
+ u32 n_redirects;
unsigned long rate_last;
union {
struct list_head gc_list;
--- a/net/ipv4/inetpeer.c
+++ b/net/ipv4/inetpeer.c
@@ -464,6 +464,7 @@ relookup:
atomic_set(&p->rid, 0);
p->metrics[RTAX_LOCK-1] = INETPEER_METRICS_NEW;
p->rate_tokens = 0;
+ p->n_redirects = 0;
/* 60*HZ is arbitrary, but chosen enough high so that the first
* calculation of tokens is at its maximum.
*/
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -864,13 +864,15 @@ void ip_rt_send_redirect(struct sk_buff
/* No redirected packets during ip_rt_redirect_silence;
* reset the algorithm.
*/
- if (time_after(jiffies, peer->rate_last + ip_rt_redirect_silence))
+ if (time_after(jiffies, peer->rate_last + ip_rt_redirect_silence)) {
peer->rate_tokens = 0;
+ peer->n_redirects = 0;
+ }
/* Too many ignored redirects; do not send anything
* set dst.rate_last to the last seen redirected packet.
*/
- if (peer->rate_tokens >= ip_rt_redirect_number) {
+ if (peer->n_redirects >= ip_rt_redirect_number) {
peer->rate_last = jiffies;
goto out_put_peer;
}
@@ -887,6 +889,7 @@ void ip_rt_send_redirect(struct sk_buff
icmp_send(skb, ICMP_REDIRECT, ICMP_REDIR_HOST, gw);
peer->rate_last = jiffies;
++peer->rate_tokens;
+ ++peer->n_redirects;
#ifdef CONFIG_IP_ROUTE_VERBOSE
if (log_martians &&
peer->rate_tokens == ip_rt_redirect_number)
next prev parent reply other threads:[~2019-02-21 14:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-21 14:35 [PATCH 3.18 00/13] 3.18.136-stable review Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 3.18 01/13] net: fix IPv6 prefix route residue Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 3.18 02/13] sky2: Increase D3 delay again Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 3.18 03/13] tcp: tcp_v4_err() should be more careful Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 3.18 04/13] tcp: clear icsk_backoff in tcp_write_queue_purge() Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 3.18 05/13] vxlan: test dev->flags & IFF_UP before calling netif_rx() Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 3.18 06/13] vsock: cope with memory allocation failure at socket creation time Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 3.18 07/13] net: stmmac: Fix a race in EEE enable callback Greg Kroah-Hartman
2019-02-21 14:35 ` Greg Kroah-Hartman [this message]
2019-02-21 14:35 ` [PATCH 3.18 09/13] hwmon: (lm80) Fix missing unlock on error in set_fan_div() Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 3.18 10/13] kvm: fix kvm_ioctl_create_device() reference counting (CVE-2019-6974) Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 3.18 11/13] net/x25: do not hold the cpu too long in x25_new_lci() Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 3.18 12/13] mISDN: fix a race in dev_expire_timer() Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 3.18 13/13] ax25: fix possible use-after-free Greg Kroah-Hartman
2019-02-21 18:19 ` [PATCH 3.18 00/13] 3.18.136-stable review kernelci.org bot
2019-02-22 22:55 ` shuah
2019-02-22 23:30 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190221125240.937496983@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.bianconi@redhat.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).