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
| ||
|
Message-ID: <20190517141709.GA25473@unicorn.suse.cz> Date: Fri, 17 May 2019 16:17:09 +0200 From: Michal Kubecek <mkubecek@...e.cz> To: netdev@...r.kernel.org Cc: "Jason A. Donenfeld" <Jason@...c4.com>, emersonbernier@...anota.com, dsahern@...il.com, Stephen Hemminger <stephen@...workplumber.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, 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 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 With recent kernel and iproute2 5.1, I get alaris:~ # ip route get 172.17.1.2/24 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