From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville Nuorvala Subject: Re: [PATCH 6/6] IPv6: Fix infinite loop if no matching IPv6 tunnel found Date: Fri, 03 Nov 2006 11:08:52 +0200 Message-ID: <454B0724.1070609@tcs.hut.fi> References: <4549D8E7.1040409@tcs.hut.fi> <20061102.215900.15793371.yoshfuji@linux-ipv6.org> <4549EFA7.50004@tcs.hut.fi> <20061102.231810.119656005.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: davem@davemloft.net, netdev@vger.kernel.org Return-path: Received: from neon.tcs.hut.fi ([130.233.215.20]:11158 "EHLO mail.tcs.hut.fi") by vger.kernel.org with ESMTP id S1752721AbWKCJIy (ORCPT ); Fri, 3 Nov 2006 04:08:54 -0500 To: YOSHIFUJI Hideaki In-Reply-To: <20061102.231810.119656005.yoshfuji@linux-ipv6.org> Sender: netdev-owner@vger.kernel.org List-Id: netdev.vger.kernel.org YOSHIFUJI Hideaki wrote: > In article <4549EFA7.50004@tcs.hut.fi> (at Thu, 02 Nov 2006 15:16:23 +0200), Ville Nuorvala says: > >> On 11/02/06 14:59, YOSHIFUJI Hideaki wrote: >>> In article <4549D8E7.1040409@tcs.hut.fi> (at Thu, 02 Nov 2006 13:39:19 +0200), Ville Nuorvala says: >>> >>>> read_unlock(&ip6ip6_lock); >>>> - return 1; >>>> - >>>> + icmpv6_send(skb, ICMPV6_DEST_UNREACH, >>>> + ICMPV6_ADDR_UNREACH, 0, skb->dev); >>>> discard: >>> I'd argue this. We probably should not send back any ICMPv6 packets >>> to the original sender in this case to avoid DoS. >> Sorry, I don't follow you. I don't see the DoS scenario here (after we >> apply the patch, that is ;-). > > Well, leaving aside whether sending icmpv6 is good thing (*), > the code for sending icmpv6 was moved from ip6_tunnel.c > to tunnel6.c by commit-id 50fba2aa7cefa6b0e1768cb350c9e69042320c03 > by Herbert. > > The ip6_tunnel.c change that Herbert made does not seem consistent > with ipip.c change. To fix your issue the appropriate change is just > fall through to discard section, as we're doing for ipip.c. Ah, I hadn't noticed Herbert's patch. It actually appears to fix the problem I was trying to fix here. AFAIK Tero experienced the infinite loop on a 2.6.16 kernel. Regards, Ville