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: <20130710111504.GA15411@order.stressinduktion.org>
Date:	Wed, 10 Jul 2013 13:15:04 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Nicolas Dichtel <nicolas.dichtel@...nd.com>
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

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.

Thanks for looking into this,

  Hannes

--
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