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]
Date:   Wed, 14 Mar 2018 14:22:17 +0200
From:   Ido Schimmel <idosch@...sch.org>
To:     David Ahern <dsahern@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH v4 net-next 2/6] net/ipv6: Change address check to always
 take a device argument

On Tue, Mar 13, 2018 at 08:29:37AM -0700, David Ahern wrote:
> ipv6_chk_addr_and_flags determines if an address is a local address and
> optionally if it is an address on a specific device. For example, it is
> called by ip6_route_info_create to determine if a given gateway address
> is a local address. The address check 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.
> 
> ipv6_chk_addr_and_flags needs to allow callers to always pass in a device
> with a separate argument to not limit the address to the specific device.
> The device is used used to determine the L3 domain of interest.
> 
> To that end add an argument to skip the device check and update callers
> to always pass a device where possible and use the new argument to mean
> any address in the domain.
> 
> Update a handful of users of ipv6_chk_addr with a NULL dev argument. This
> patch handles the change to these callers without adding the domain check.
> 
> 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. The check is done
> twice to avoid this error.
> 
> Signed-off-by: David Ahern <dsahern@...il.com>

Reviewed-by: Ido Schimmel <idosch@...lanox.com>

Thanks for the detailed commit message.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ