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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 17 May 2019 16:17:09 +0200
From:   Michal Kubecek <>
Cc:     "Jason A. Donenfeld" <>,,,
        Stephen Hemminger <>,
        Alexey Kuznetsov <>,
        David Miller <>,
Subject: Re: 5.1 `ip route get addr/cidr` regression

On Fri, May 17, 2019 at 12:22:41PM +0200, 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 dev wg0
> + ip link set mtu 1420 up dev wg0
> + ip route get
> broadcast dev wg0 src uid 0
>    cache <local,brd>
> Behavior on 5.1:
> + ip link add wg0 type dummy
> + ip address add dev wg0
> + ip link set mtu 1420 up dev wg0
> + ip route get
> RTNETLINK answers: Invalid argument

With recent kernel and iproute2 5.1, I get

  alaris:~ # ip route get
  Error: ipv4: Invalid values in header for route get request.

This message comes from kernel commit a00302b60777 ("net: ipv4: route:
perform strict checks also for doit handlers") which only considers the
range valid if the prefix is /32 (a single address).

But these checks are only performed when userspace requests strict
validation which iproute2 does since (iproute2) commit aea41afcfd6d ("ip
bridge: Set NETLINK_GET_STRICT_CHK on socket"). So I would say the
change is a result of the combination of kernel (5.1) commit
a00302b60777 and iproute2 (5.0) commit aea41afcfd6d.

> 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
> wg-quick(8) code accordingly. But FYI, this is unexpected userspace
> breakage.

AFAIK the purpose of 'ip route get' always was to let the user check
the result of a route lookup, i.e. "what route would be used if I sent
a packet to an address". To be honest I would have to check how exactly
was "ip route get <addr>/<prefixlen>" implemented before.

Michal Kubecek

Powered by blists - more mailing lists