netdev - Re: Unable to flush ICMP redirect routes in kernel 3.0+

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: <20111118150512.5f66f7d2@asterix.rh>
Date:	Fri, 18 Nov 2011 15:05:12 -0200
From:	Flavio Leitner <fbl@...hat.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	David Miller <davem@...emloft.net>,
	Ivan Zahariev <famzah@...soft.com>, netdev@...r.kernel.org,
	Vasiliy Kulikov <segoon@...nwall.com>
Subject: Re: Unable to flush ICMP redirect routes in kernel 3.0+

On Fri, 18 Nov 2011 17:34:06 +0100
Eric Dumazet <eric.dumazet@...il.com> wrote:

> Le vendredi 18 novembre 2011 à 14:30 -0200, Flavio Leitner a écrit :
> 
> > I know we are reverting to get it fixed, but this adds the routing
> > cache back, so what is the plan? Revert to get it working and then
> > think on new approach to remove the route cache again later?
> > 
> > I had one previous patch using the routing cache posted to the list,
> > but it won't fix the route flush problem.
> > 
> 
> I dont "add the routing cache back".

Sorry, I meant that we are trying to avoid doing this:
+			hash = rt_hash(daddr, skeys[s], ikeys[i],rt_genid(net));
+
+			rthp = &rt_hash_table[hash].chain;
+
+			while ((rt = rcu_dereference(*rthp)) != NULL) {
+				rthp = &rt->dst.rt_next;

anyway, see below.

> Note I only fix existing route entries in the cache ;)
Exactly.
 
> A "revert" is probably safe, since we should push a fix for
> 3.0/3.1/3.2 kernels...

I agree that reverting is probably safe.
fbl

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