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
| ||
|
Date: Tue, 6 Mar 2018 17:01:48 +0200 From: Ido Schimmel <idosch@...sch.org> To: David Ahern <dsahern@...il.com> Cc: netdev@...r.kernel.org Subject: Re: [PATCH v2 net-next 2/5] net/ipv6: Address checks need to consider the L3 domain On Mon, Mar 05, 2018 at 01:34:03PM -0800, David Ahern wrote: > ipv6_chk_addr_and_flags determines if an address is a local address. It > is called by ip6_route_info_create to validate a gateway address is not a > local address. It currently does not consider L3 domains and as a result > does not allow a route to be added in one VRF if the nexthop points to > an address in a second VRF. e.g., > > $ ip route add 2001:db8:1::/64 vrf r2 via 2001:db8:102::23 > Error: Invalid gateway address. > > where 2001:db8:102::23 is an address on an interface in vrf r1. > > Resolve by comparing the l3mdev for the passed in device and requiring an > l3mdev match with the device containing an address. The intent of checking > for an address on the specified device versus any device in the domain is > mantained by a new argument to skip the check between the passed in device > and the device with the address. > > Update the handful of users of ipv6_chk_addr with a NULL dev argument: I see at least two callers from net/sctp/ipv6.c that pass a NULL argument, which means they only want an address check, but you pass 'false' to 'skip_dev_check'. > - anycast to call ipv6_chk_addr_and_flags. If the device is given by the > user, look for the given address across the L3 domain. If the index is > not given, the default table is presumed so only addresses on devices > not enslaved are considered. > > - ip6_tnl_rcv_ctl - local address must exist on device, remote address > can not exist in L3 domain; only remote check needs to be updated but > do both for consistency. > > ip6_validate_gw needs to handle 2 cases - one where the device is given > as part of the nexthop spec and the other where the device is resolved. > There is at least 1 VRF case where deferring the check to only after > the route lookup has resolved the device fails with an unintuitive error > "RTNETLINK answers: No route to host" as opposed to the preferred > "Error: Gateway can not be a local address." The 'no route to host' > error is because of the fallback to a full lookup. > > Signed-off-by: David Ahern <dsahern@...il.com>
Powered by blists - more mailing lists