linux-kernel - Re: [PATCH] ipv6: Fixed source specific default route handling.

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]

Message-ID: <5586F1F8.1070800@universe-factory.net>
Date:	Sun, 21 Jun 2015 19:18:48 +0200
From:	Matthias Schiffer <mschiffer@...verse-factory.net>
To:	Markus Stenberg <markus.stenberg@....fi>,
	"David S. Miller" <davem@...emloft.net>,
	Alexey Kuznetsov <kuznet@....inr.ac.ru>,
	James Morris <jmorris@...ei.org>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
	Patrick McHardy <kaber@...sh.net>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, Steven Barth <steven@...link.org>
Subject: Re: [PATCH] ipv6: Fixed source specific default route handling.

On 05/05/2015 12:36 PM, Markus Stenberg wrote:
> If there are only IPv6 source specific default routes present, the
> host gets -ENETUNREACH on e.g. connect() because ip6_dst_lookup_tail
> calls ip6_route_output first, and given source address any, it fails,
> and ip6_route_get_saddr is never called.
> 
> The change is to use the ip6_route_get_saddr, even if the initial
> ip6_route_output fails, and then doing ip6_route_output _again_ after
> we have appropriate source address available.
> 
> Note that this is '99% fix' to the problem; a correct fix would be to
> do route lookups only within addrconf.c when picking a source address,
> and never call ip6_route_output before source address has been
> populated.
> 
> Signed-off-by: Markus Stenberg <markus.stenberg@....fi>
> ---
>  net/ipv6/ip6_output.c | 39 +++++++++++++++++++++++++++++++--------
>  net/ipv6/route.c      |  5 +++--
>  2 files changed, 34 insertions(+), 10 deletions(-)
> 
...

So... how does ip6_route_get_saddr() select the source address when no
route is given? OpenWrt has recently started relying on this patch and
I'm seeing quite weird source address selection behaviour (@Steven:
especially since OpenWrt commit r45941).

Steps to reproduce:

  ip l add test link eth0 type macvlan
  ip l set test up
  ip a add fd00::20/64 dev eth0
  ip a add fd00::1/128 dev test

Upto here everything is okay,

  ping6 fd00::10

will use the correct source address fd00::20.

Now I add an additional source-specific route:

  ip r add fd00::/64 from fd00::/64 dev eth0

(this certainly looks like a contrived example, but the configuration
OpenWrt's netifd/odhcp6c creates is similar)

Without this patch, the ping will fail with 'network unreachable' (which
is weird by itself - why does the source-specific route shadow the
generic route even though no source address has been chosen?). But after
applying this patch, the kernel will now choose the address with the
longest common prefix with the destination, which is fd00::1 - even
though this address is assigned as /128.

Adding a prefsrc attribute to the source-specific route doesn't have an
effect as ip6_route_get_saddr() doesn't even get the route when the
non-source-specific ip6_route_output() has failed. Thus, there's
currently no way (to my knowledge) to specify the source address to use
when source-specific routes are involved...

Matthias

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)