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]

Message-ID: <20170922122315.GA3446@bistromath.localdomain>
Date:   Fri, 22 Sep 2017 14:23:15 +0200
From:   Sabrina Dubroca <sd@...asysnail.net>
To:     Eric Dumazet <eric.dumazet@...il.com>
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

2017-09-22, 04:05:09 -0700, Eric Dumazet wrote:
> 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 ?

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