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: <20130712161935.GB31912@order.stressinduktion.org>
Date:	Fri, 12 Jul 2013 18:19:35 +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 Fri, Jul 12, 2013 at 02:04:45PM +0200, Nicolas Dichtel wrote:
> It's possible to add a glue to check this counter when we play with these 
> flags, but it's ugly.
> 
> Maybe the check against RTF_EXPIRES is fundamentally wrong. Checking 
> RTF_ADDRCONF|RTF_DYNAMIC should be enough, what do you think?

Yes, this seems to be the best option now. I will audit the source if
RTF_ADDRCONF and RTF_DYNAMIC are immutable after dst construction and
if other errors could arise for that and would go with this solution then.

What do you think about making ecmp routes explicit by adding RTF_ECMP
flag?

> In another hand, we can discuss about the initial assumption, that was 
> "only static routes are part of ECMP routes". I'm thinking of what are the 
> consequence if we accept to accept all routes, without checking any flags.

I don't have a good feeling about that. But I may be wrong.

Greetings,

  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