netdev - Re: [PATCH RFC] ipv6: fix route selection if kernel is not compiled with CONFIG_IPV6_ROUTER

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: <51DD4ECA.1080506@6wind.com>
Date:	Wed, 10 Jul 2013 14:08:42 +0200
From:	Nicolas Dichtel <nicolas.dichtel@...nd.com>
To:	hannes@...essinduktion.org
CC:	netdev@...r.kernel.org, yoshfuji@...ux-ipv6.org,
	petrus.lt@...il.com, davem@...emloft.net
Subject: Re: [PATCH RFC] ipv6: fix route selection if kernel is not compiled
 with CONFIG_IPV6_ROUTER_PREF

Le 10/07/2013 13:15, Hannes Frederic Sowa a écrit :
> On Wed, Jul 10, 2013 at 09:54:58AM +0200, Nicolas Dichtel wrote:
>> Le 09/07/2013 23:57, Hannes Frederic Sowa a écrit :
>>> Are we sure we decrement all sibling's rt6i_nsiblings? Shouldn't we
>>> start iterating from fn->leaf? But this does not seem to cause it,
>>> because my trace does not report any calls to fib6_del_route.
>> Note sure to follow you, but all siblings are listed in rt6i_siblings, so
>> it must be enough.
>
> My hunch was to iterate over fn->leaf->rt_next and compare the metrics like we
> do when adding a new route. Then take that rt6_info->rt6i_siblings list_head
> to iterate over the remaining siblings. But I did not review that part
> carefully, need to check later.
>
>>> You could try reproduce it by having an interface autoconfigured with
>>> a default router with NUD_VALID neighbour. I then added an unused vlan
>>> interface (vid 100 in my case) and added the following ip addresses:
>>>
>>> ip -6 a a 2001:ffff::1/64 dev eth0.100
>>> ip -6 r a 2000::/3 nexthop via 2001:ffff::30 nexthop via 2001:ffff::31
>>> nexthop via 2001:ffff::32 nexthop via 2001:ffff::33
>>>
>>> (all nexthops should not be reachable)
>>>
>>> After starting a ping6 2000::1 the box should panic soon, after the
>>> first nexthop entry times out.
>>>
>>> Perhaps you could give me a hint?
>> I will run some tests with your patch. Will see.
>>
>> I assume you didn't reproduce this without your patch.
>
> Current kernel does not correctly select more specific routes, so these routes
> are not even tried and the logic should not be excercised.
>
> Ah, sorry, you should also compile your kernel without
> CONFIG_IPV6_ROUTER_PREF, too, if you try to reproduce it.
I've done this.

My conf (eth1 autoconfigured, I use net-next + your patch):
vconfig add eth1 100
ifconfig eth1.100 up
ip -6 a a 2001:ffff::1/64 dev eth1.100
ip -6 r a 2000::/3 nexthop via 2001:ffff::30 nexthop via 2001:ffff::31 nexthop 
via 2001:ffff::32 nexthop via 2001:ffff::33
ping6 2000::1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html