netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH net] net: ipv4: don't allow setting net.ipv4.route.min_pmtu below 68
@ 2018-02-26 15:13 Sabrina Dubroca
  2018-02-27 16:13 ` David Miller
  0 siblings, 1 reply; 2+ messages in thread
From: Sabrina Dubroca @ 2018-02-26 15:13 UTC (permalink / raw)
  To: netdev; +Cc: jishi, sbrivio, Sabrina Dubroca

According to RFC 1191 sections 3 and 4, ICMP frag-needed messages
indicating an MTU below 68 should be rejected:

    A host MUST never reduce its estimate of the Path MTU below 68
    octets.

and (talking about ICMP frag-needed's Next-Hop MTU field):

    This field will never contain a value less than 68, since every
    router "must be able to forward a datagram of 68 octets without
    fragmentation".

Furthermore, by letting net.ipv4.route.min_pmtu be set to negative
values, we can end up with a very large PMTU when (-1) is cast into u32.

Let's also make ip_rt_min_pmtu a u32, since it's only ever compared to
unsigned ints.

Reported-by: Jianlin Shi <jishi@redhat.com>
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
---
 net/ipv4/route.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index a4f44d815a61..95484376ec9b 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -128,10 +128,13 @@ static int ip_rt_redirect_silence __read_mostly	= ((HZ / 50) << (9 + 1));
 static int ip_rt_error_cost __read_mostly	= HZ;
 static int ip_rt_error_burst __read_mostly	= 5 * HZ;
 static int ip_rt_mtu_expires __read_mostly	= 10 * 60 * HZ;
-static int ip_rt_min_pmtu __read_mostly		= 512 + 20 + 20;
+static u32 ip_rt_min_pmtu __read_mostly		= 512 + 20 + 20;
 static int ip_rt_min_advmss __read_mostly	= 256;
 
 static int ip_rt_gc_timeout __read_mostly	= RT_GC_TIMEOUT;
+
+static int ip_min_valid_pmtu __read_mostly	= IPV4_MIN_MTU;
+
 /*
  *	Interface to generic destination cache.
  */
@@ -2933,7 +2936,8 @@ static struct ctl_table ipv4_route_table[] = {
 		.data		= &ip_rt_min_pmtu,
 		.maxlen		= sizeof(int),
 		.mode		= 0644,
-		.proc_handler	= proc_dointvec,
+		.proc_handler	= proc_dointvec_minmax,
+		.extra1		= &ip_min_valid_pmtu,
 	},
 	{
 		.procname	= "min_adv_mss",
-- 
2.16.2

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH net] net: ipv4: don't allow setting net.ipv4.route.min_pmtu below 68
  2018-02-26 15:13 [PATCH net] net: ipv4: don't allow setting net.ipv4.route.min_pmtu below 68 Sabrina Dubroca
@ 2018-02-27 16:13 ` David Miller
  0 siblings, 0 replies; 2+ messages in thread
From: David Miller @ 2018-02-27 16:13 UTC (permalink / raw)
  To: sd; +Cc: netdev, jishi, sbrivio

From: Sabrina Dubroca <sd@queasysnail.net>
Date: Mon, 26 Feb 2018 16:13:43 +0100

> According to RFC 1191 sections 3 and 4, ICMP frag-needed messages
> indicating an MTU below 68 should be rejected:
> 
>     A host MUST never reduce its estimate of the Path MTU below 68
>     octets.
> 
> and (talking about ICMP frag-needed's Next-Hop MTU field):
> 
>     This field will never contain a value less than 68, since every
>     router "must be able to forward a datagram of 68 octets without
>     fragmentation".
> 
> Furthermore, by letting net.ipv4.route.min_pmtu be set to negative
> values, we can end up with a very large PMTU when (-1) is cast into u32.
> 
> Let's also make ip_rt_min_pmtu a u32, since it's only ever compared to
> unsigned ints.
> 
> Reported-by: Jianlin Shi <jishi@redhat.com>
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> Reviewed-by: Stefano Brivio <sbrivio@redhat.com>

Applied and queued up for -stable, thanks Sabrina.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-02-27 16:14 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-02-26 15:13 [PATCH net] net: ipv4: don't allow setting net.ipv4.route.min_pmtu below 68 Sabrina Dubroca
2018-02-27 16:13 ` David Miller

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).