[net-next 0/2] add device MTU validation check

This patch serial add device MTU validation check, so that only valid mtu value 
can be set when adding new device.

Zhang Shengju (2):
  dummy: add device MTU validation check
  ifb: add device MTU validation check

 drivers/net/dummy.c | 8 ++++++++
 drivers/net/ifb.c   | 8 ++++++++
 2 files changed, 16 insertions(+)

-- 
1.8.3.1

Currently, any mtu value can be assigned when adding a new ifb device:
[~]# ip link add name ifb2 mtu 100000 type ifb
[~]# ip link show ifb2
18: ifb2: <BROADCAST,NOARP> mtu 100000 qdisc noop state DOWN mode DEFAULT group default qlen 32
    link/ether 7a:bf:f4:63:da:d1 brd ff:ff:ff:ff:ff:ff

This patch adds device MTU validation check.

Signed-off-by: Zhang Shengju <redacted>
---
 drivers/net/ifb.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
index 8870bd2..ce84ad2 100644
--- a/drivers/net/ifb.c
+++ b/drivers/net/ifb.c

@@ -282,6 +282,14 @@ static int ifb_validate(struct nlattr *tb[], struct nlattr *data[],
 		if (!is_valid_ether_addr(nla_data(tb[IFLA_ADDRESS])))
 			return -EADDRNOTAVAIL;
 	}
+
+	if (tb[IFLA_MTU]) {
+		u32 mtu = nla_get_u32(tb[IFLA_MTU]);
+
+		if (mtu < ETH_MIN_MTU || mtu > ETH_DATA_LEN)
+			return -EINVAL;
+	}
+
 	return 0;
 }
 

-- 
1.8.3.1

Currently, any mtu value can be assigned when adding a new dummy device:
[~]# ip link add name dummy1 mtu 100000 type dummy
[~]# ip link show dummy1
15: dummy1: <BROADCAST,NOARP> mtu 100000 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 0a:61:6b:16:14:ce brd ff:ff:ff:ff:ff:ff

This patch adds device MTU validation check.

Signed-off-by: Zhang Shengju <redacted>
---
 drivers/net/dummy.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c
index e31ab3b..0276b2b 100644
--- a/drivers/net/dummy.c
+++ b/drivers/net/dummy.c

@@ -365,6 +365,14 @@ static int dummy_validate(struct nlattr *tb[], struct nlattr *data[],
 		if (!is_valid_ether_addr(nla_data(tb[IFLA_ADDRESS])))
 			return -EADDRNOTAVAIL;
 	}
+
+	if (tb[IFLA_MTU]) {
+		u32 mtu = nla_get_u32(tb[IFLA_MTU]);
+
+		if (mtu > ETH_MAX_MTU)
+			return -EINVAL;
+	}
+
 	return 0;
 }
 

-- 
1.8.3.1

On Thu, 2017-09-21 at 21:32 +0800, Zhang Shengju wrote:

Currently, any mtu value can be assigned when adding a new dummy device:
[~]# ip link add name dummy1 mtu 100000 type dummy
[~]# ip link show dummy1
15: dummy1: <BROADCAST,NOARP> mtu 100000 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 0a:61:6b:16:14:ce brd ff:ff:ff:ff:ff:ff

This patch adds device MTU validation check.

What is wrong with big MTU on dummy ?

If this is a generic rule, this check should belong in core network
stack.

You do not verify/validate nla_len(tb[IFLA_MTU]).

Do not ever trust user space.

+
+		if (mtu > ETH_MAX_MTU)
+			return -EINVAL;
+	}
+
 	return 0;
 }
 

On Thu, 21 Sep 2017 21:32:02 +0800
Zhang Shengju [off-list ref] wrote:

What about running ifb with packets coming from devices with jumbo frames?
Also since ifb is an input only device, MTU doesn't matter.

-----Original Message-----
From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
Sent: 2017年9月21日 23:02
To: Zhang Shengju <redacted>
Cc: davem@davemloft.net; willemb@google.com;
stephen@networkplumber.org; netdev@vger.kernel.org
Subject: Re: [net-next 1/2] dummy: add device MTU validation check

On Thu, 2017-09-21 at 21:32 +0800, Zhang Shengju wrote:

quoted

Currently, any mtu value can be assigned when adding a new dummy device:
[~]# ip link add name dummy1 mtu 100000 type dummy [~]# ip link show
dummy1
15: dummy1: <BROADCAST,NOARP> mtu 100000 qdisc noop state DOWN

mode DEFAULT group default qlen 1000

quoted

    link/ether 0a:61:6b:16:14:ce brd ff:ff:ff:ff:ff:ff

This patch adds device MTU validation check.

What is wrong with big MTU on dummy ?

If this is a generic rule, this check should belong in core network stack.

dummy_setup() function setup mtu range: [0, ETH_MAX_MTU]. 
This will be checked at dev_set_mtu() function in core network stack.

So if you add a new dummy device without specify mtu value, you can't set a value out of range [0, ETH_MAX_MTU] afterward.
BUT you can set any mtu when adding new device. This cause an inconsistence.

quoted

Signed-off-by: Zhang Shengju <redacted>
---
 drivers/net/dummy.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c index

e31ab3b..0276b2b 100644

--- a/drivers/net/dummy.c
+++ b/drivers/net/dummy.c

@@ -365,6 +365,14 @@ static int dummy_validate(struct nlattr *tb[], struct

nlattr *data[],

quoted

 		if (!is_valid_ether_addr(nla_data(tb[IFLA_ADDRESS])))
 			return -EADDRNOTAVAIL;
 	}
+
+	if (tb[IFLA_MTU]) {
+		u32 mtu = nla_get_u32(tb[IFLA_MTU]);

You do not verify/validate nla_len(tb[IFLA_MTU]).

Do not ever trust user space.

MTU attribute is just u32, do you think it's necessary to check the length? 
Actually I don't see any place to check the length of mtu attribute in network stack code. 

quoted

+
+		if (mtu > ETH_MAX_MTU)
+			return -EINVAL;
+	}
+
 	return 0;
 }

-----Original Message-----
From: Stephen Hemminger [mailto:stephen@networkplumber.org]
Sent: 2017年9月21日 23:10
To: Zhang Shengju <redacted>
Cc: davem@davemloft.net; willemb@google.com; netdev@vger.kernel.org
Subject: Re: [net-next 2/2] ifb: add device MTU validation check

On Thu, 21 Sep 2017 21:32:02 +0800
Zhang Shengju [off-list ref] wrote:

quoted

Currently, any mtu value can be assigned when adding a new ifb device:
[~]# ip link add name ifb2 mtu 100000 type ifb [~]# ip link show ifb2
18: ifb2: <BROADCAST,NOARP> mtu 100000 qdisc noop state DOWN mode

DEFAULT group default qlen 32

quoted

    link/ether 7a:bf:f4:63:da:d1 brd ff:ff:ff:ff:ff:ff

This patch adds device MTU validation check.

Signed-off-by: Zhang Shengju <redacted>
---
 drivers/net/ifb.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c index

8870bd2..ce84ad2 100644

--- a/drivers/net/ifb.c
+++ b/drivers/net/ifb.c

@@ -282,6 +282,14 @@ static int ifb_validate(struct nlattr *tb[], struct

nlattr *data[],

quoted

 		if (!is_valid_ether_addr(nla_data(tb[IFLA_ADDRESS])))
 			return -EADDRNOTAVAIL;
 	}
+
+	if (tb[IFLA_MTU]) {
+		u32 mtu = nla_get_u32(tb[IFLA_MTU]);
+
+		if (mtu < ETH_MIN_MTU || mtu > ETH_DATA_LEN)
+			return -EINVAL;
+	}
+
 	return 0;
 }

What about running ifb with packets coming from devices with jumbo frames?
Also since ifb is an input only device, MTU doesn't matter.

Actually ifb_setup() function setup ifb valid MTU range: [68, 1500], and
this will be check at dev_set_mtu() function. 
You can't setup mtu out of this range after creation, but you can set any
value when adding new ifb device.
This is inconsistent, and I think we should add this check at creation time 

BRs,
ZSJ

2017-09-21, 08:02:18 -0700, Eric Dumazet wrote:

On Thu, 2017-09-21 at 21:32 +0800, Zhang Shengju wrote:

quoted

Currently, any mtu value can be assigned when adding a new dummy device:
[~]# ip link add name dummy1 mtu 100000 type dummy
[~]# ip link show dummy1
15: dummy1: <BROADCAST,NOARP> mtu 100000 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 0a:61:6b:16:14:ce brd ff:ff:ff:ff:ff:ff

This patch adds device MTU validation check.

What is wrong with big MTU on dummy ?

It looks like the "centralize MTU checking" series broke that, but
only for changing the MTU on an existing dummy device. Commit
a52ad514fdf3 defined min_mtu/max_mtu in ether_setup, which dummy uses,
but there was no MTU check in dummy prior to that commit.

If this is a generic rule, this check should belong in core network
stack.

quoted

Signed-off-by: Zhang Shengju <redacted>
---
 drivers/net/dummy.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c
index e31ab3b..0276b2b 100644
--- a/drivers/net/dummy.c
+++ b/drivers/net/dummy.c

@@ -365,6 +365,14 @@ static int dummy_validate(struct nlattr *tb[], struct nlattr *data[],
 		if (!is_valid_ether_addr(nla_data(tb[IFLA_ADDRESS])))
 			return -EADDRNOTAVAIL;
 	}
+
+	if (tb[IFLA_MTU]) {
+		u32 mtu = nla_get_u32(tb[IFLA_MTU]);

You do not verify/validate nla_len(tb[IFLA_MTU]).

I think ifla_policy already performs that check:


static const struct nla_policy ifla_policy[IFLA_MAX+1] = {
[...]
	[IFLA_MTU]		= { .type = NLA_U32 },


static int rtnl_newlink(struct sk_buff *skb, struct nlmsghdr *nlh,
			struct netlink_ext_ack *extack)
{
[...]
	err = nlmsg_parse(nlh, sizeof(*ifm), tb, IFLA_MAX, ifla_policy, extack);


-- 
Sabrina

On Fri, 2017-09-22 at 10:56 +0200, Sabrina Dubroca wrote:

2017-09-21, 08:02:18 -0700, Eric Dumazet wrote:

quoted

On Thu, 2017-09-21 at 21:32 +0800, Zhang Shengju wrote:

quoted

Currently, any mtu value can be assigned when adding a new dummy device:
[~]# ip link add name dummy1 mtu 100000 type dummy
[~]# ip link show dummy1
15: dummy1: <BROADCAST,NOARP> mtu 100000 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 0a:61:6b:16:14:ce brd ff:ff:ff:ff:ff:ff

This patch adds device MTU validation check.

What is wrong with big MTU on dummy ?

It looks like the "centralize MTU checking" series broke that, but
only for changing the MTU on an existing dummy device. Commit
a52ad514fdf3 defined min_mtu/max_mtu in ether_setup, which dummy uses,
but there was no MTU check in dummy prior to that commit.

It looks like we accept big mtu on loopback, right ?

lpaa23:~# ifconfig lo mtu 100000
lpaa23:~# ifconfig lo
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:100000  Metric:1
          RX packets:3823 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3823 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:759159 (759.1 KB)  TX bytes:759159 (759.1 KB)

Also we accept very small MTU as well (although this automatically
removes IP addresses, as one would expect)

lpaa23:~# ifconfig lo mtu 50
lpaa23:~# ifconfig lo
lo        Link encap:Local Loopback  
          UP LOOPBACK RUNNING  MTU:50  Metric:1
          RX packets:4052 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4052 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:806274 (806.2 KB)  TX bytes:806274 (806.2 KB)



So, why dummy devices would not accept bit MTU ?

Do we have some fundamental assumption in the stack ?

If yes, we need to fix loopback urgently, it is more important than
dummy.

Thanks.

2017-09-22, 04:05:09 -0700, Eric Dumazet wrote:

On Fri, 2017-09-22 at 10:56 +0200, Sabrina Dubroca wrote:

quoted

2017-09-21, 08:02:18 -0700, Eric Dumazet wrote:

quoted

On Thu, 2017-09-21 at 21:32 +0800, Zhang Shengju wrote:

quoted

Currently, any mtu value can be assigned when adding a new dummy device:
[~]# ip link add name dummy1 mtu 100000 type dummy
[~]# ip link show dummy1
15: dummy1: <BROADCAST,NOARP> mtu 100000 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 0a:61:6b:16:14:ce brd ff:ff:ff:ff:ff:ff

This patch adds device MTU validation check.

What is wrong with big MTU on dummy ?

It looks like the "centralize MTU checking" series broke that, but
only for changing the MTU on an existing dummy device. Commit
a52ad514fdf3 defined min_mtu/max_mtu in ether_setup, which dummy uses,
but there was no MTU check in dummy prior to that commit.

It looks like we accept big mtu on loopback, right ?

Yes. I only meant that before commit a52ad514fdf3, there was no range
check on dummy's MTU. Commit 25e3e84b183a ("dummy: expend mtu range
for dummy device") and 8b1efc0f83f1 ("net: remove MTU limits on a few
ether_setup callers") fixed that only partially. It's the same with
ifb, btw, it didn't have any check before a52ad514fdf3, so we should
set min_mtu = max_mtu = 0.

-- 
Sabrina

-----Original Message-----
From: Sabrina Dubroca [mailto:sd@queasysnail.net]
Sent: 2017年9月22日 20:23
To: Eric Dumazet <redacted>
Cc: Jarod Wilson <redacted>; Zhang Shengju
[off-list ref]; davem@davemloft.net;
willemb@google.com; stephen@networkplumber.org;
netdev@vger.kernel.org
Subject: Re: [net-next 1/2] dummy: add device MTU validation check

2017-09-22, 04:05:09 -0700, Eric Dumazet wrote:

quoted

On Fri, 2017-09-22 at 10:56 +0200, Sabrina Dubroca wrote:

quoted

2017-09-21, 08:02:18 -0700, Eric Dumazet wrote:

quoted

On Thu, 2017-09-21 at 21:32 +0800, Zhang Shengju wrote:

quoted

Currently, any mtu value can be assigned when adding a new dummy

device:

quoted

quoted

quoted

quoted

[~]# ip link add name dummy1 mtu 100000 type dummy [~]# ip link
show dummy1
15: dummy1: <BROADCAST,NOARP> mtu 100000 qdisc noop state

DOWN mode DEFAULT group default qlen 1000

quoted

quoted

quoted

quoted

    link/ether 0a:61:6b:16:14:ce brd ff:ff:ff:ff:ff:ff

This patch adds device MTU validation check.

What is wrong with big MTU on dummy ?

It looks like the "centralize MTU checking" series broke that, but
only for changing the MTU on an existing dummy device. Commit
a52ad514fdf3 defined min_mtu/max_mtu in ether_setup, which dummy
uses, but there was no MTU check in dummy prior to that commit.

It looks like we accept big mtu on loopback, right ?

Yes. I only meant that before commit a52ad514fdf3, there was no range check
on dummy's MTU. Commit 25e3e84b183a ("dummy: expend mtu range for
dummy device") and 8b1efc0f83f1 ("net: remove MTU limits on a few
ether_setup callers") fixed that only partially. It's the same with ifb, btw, it
didn't have any check before a52ad514fdf3, so we should set min_mtu =
max_mtu = 0.

--
Sabrina

I agree, dummy and ifb device should not have any limit on mtu, just like loopback device.
I will send v2 patch, and set min/max_mtu to zero for dummy and ifb device, thanks.

ZSJ