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  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, 17 May 2019 11:39:05 -0600
From:   David Ahern <dsahern@...il.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
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 5/17/19 11:35 AM, Stephen Hemminger wrote:
> 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...
> 

The kernel does set an extack for all EINVAL in this code path.

Not sure why Jason is not seeing that. Really odd that he hits the error
AND does not get a message back since it requires an updated ip command
to set the strict checking flag and that command understands extack.
Perhaps no libmnl?

Powered by blists - more mailing lists