From owner-freebsd-net Mon Dec 16 23:59:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C84A337B401 for ; Mon, 16 Dec 2002 23:59:16 -0800 (PST) Received: from mel-rto4.wanadoo.fr (smtp-out-4.wanadoo.fr [193.252.19.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97D1243ED4 for ; Mon, 16 Dec 2002 23:59:10 -0800 (PST) (envelope-from fabien.thomas@netasq.com) Received: from mel-rta10.wanadoo.fr (193.252.19.193) by mel-rto4.wanadoo.fr (6.7.015) id 3DF632EE0040B73C for freebsd-net@freebsd.org; Tue, 17 Dec 2002 08:59:09 +0100 Received: from localhost (193.251.0.218) by mel-rta10.wanadoo.fr (6.7.015) id 3DF6325A0034A16F; Tue, 17 Dec 2002 08:59:09 +0100 Date: Tue, 17 Dec 2002 08:59:15 +0100 From: Fabien THOMAS X-Mailer: The Bat! (v1.62 Christmas Edition) Business Reply-To: Fabien THOMAS X-Priority: 3 (Normal) Message-ID: <148722428.20021217085915@wanadoo.fr> To: Vincent Jardin Cc: freebsd-net@freebsd.org Subject: Re: Recursive encapsulation could panic the Kernel In-Reply-To: <3DF62DBD0032C2ED@mel-rta6.wanadoo.fr> References: <3DF62DBD0032C2ED@mel-rta6.wanadoo.fr> (added by postmaster@wanadoo.fr) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org we can use a TTL associated to the mbuf that is decremented each time we reach a possible 'point of loop'. the bad point is that we need a new entry in the mbuf... fabien VJ> Hi, VJ> With FreeBSD, there are many ways to create a recursive local encapsulation VJ> loop within the IPv4 and IPv6 stack. For example, this problem shows up when : VJ> - Netgraph with pptp is used or Netgraph with an ng_iface over UDP or any VJ> more complex Netgraph topologies... VJ> - gre interfaces VJ> - gif tunnels VJ> - ... VJ> There is a simple local solution that is used by gif_output() that is not VJ> protected by any mutex: VJ> /* VJ> * gif may cause infinite recursion calls when misconfigured. VJ> * We'll prevent this by introducing upper limit. VJ> * XXX: this mechanism may introduce another problem about VJ> * mutual exclusion of the variable CALLED, especially if we VJ> * use kernel thread. VJ> */ VJ> if (++called > max_gif_nesting) { VJ> log(LOG_NOTICE, VJ> "gif_output: recursively called too many times(%d)\n", VJ> called); VJ> m_freem(m); VJ> error = EIO; /* is there better errno? */ VJ> goto end; VJ> } VJ> I am wondering if a more generic solution could be found, however I do not VJ> have any idea yet ;-( VJ> I mean, is it possible to protect the kernel against any panic that could VJ> come from a mis-configuration of the routing tables ? VJ> Regards, VJ> Vincent VJ> To Unsubscribe: send mail to majordomo@FreeBSD.org VJ> with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message