netdev - Re: 5.1 `ip route get addr/cidr` regression

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: <20190517103543.149e9c6c@hermes.lan>
Date:   Fri, 17 May 2019 10:35:43 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     David Ahern <dsahern@...il.com>
Cc:     "Jason A. Donenfeld" <Jason@...c4.com>,
        emersonbernier@...anota.com, Netdev <netdev@...r.kernel.org>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        David Miller <davem@...emloft.net>, piraty1@...ox.ru
Subject: Re: 5.1 `ip route get addr/cidr` regression

On Fri, 17 May 2019 09:17:51 -0600
David Ahern <dsahern@...il.com> wrote:

> On 5/17/19 4:22 AM, Jason A. Donenfeld wrote:
> > Hi,
> > 
> > I'm back now and catching up with a lot of things. A few people have
> > mentioned to me that wg-quick(8), a bash script that makes a bunch of
> > iproute2 invocations, appears to be broken on 5.1. I've distilled the
> > behavior change down to the following.
> > 
> > Behavior on 5.0:
> > 
> > + ip link add wg0 type dummy
> > + ip address add 192.168.50.2/24 dev wg0
> > + ip link set mtu 1420 up dev wg0
> > + ip route get 192.168.50.0/24
> > broadcast 192.168.50.0 dev wg0 src 192.168.50.2 uid 0
> >    cache <local,brd>
> > 
> > Behavior on 5.1:
> > 
> > + ip link add wg0 type dummy
> > + ip address add 192.168.50.2/24 dev wg0
> > + ip link set mtu 1420 up dev wg0
> > + ip route get 192.168.50.0/24
> > RTNETLINK answers: Invalid argument  
> 
> This is a 5.1 change.
> a00302b607770 ("net: ipv4: route: perform strict checks also for doit
> handlers")
> 
> Basically, the /24 is unexpected. I'll send a patch.
> 
> > 
> > Upon investigating, I'm not sure that `ip route get` was ever suitable
> > for getting details on a particular route. So I'll adjust the  
> 
> 'ip route get <prefix> fibmatch' will show the fib entry.
> 

If you want to keep the error, the kernel should send additional
extack as to reason. EINVAL is not user friendly...