netdev - Re: [net-next 1/2] dummy: add device MTU validation check

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 22 Sep 2017 04:05:09 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Sabrina Dubroca <sd@...asysnail.net>
Cc:     Jarod Wilson <jarod@...hat.com>,
        Zhang Shengju <zhangshengju@...s.chinamobile.com>,
        davem@...emloft.net, willemb@...gle.com,
        stephen@...workplumber.org, netdev@...r.kernel.org
Subject: Re: [net-next 1/2] dummy: add device MTU validation check

On Fri, 2017-09-22 at 10:56 +0200, Sabrina Dubroca wrote:
> 2017-09-21, 08:02:18 -0700, Eric Dumazet wrote:
> > 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 ?
> 
> 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.