From owner-freebsd-net Mon Dec 16 12:26:46 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 7068937B401 for ; Mon, 16 Dec 2002 12:26:45 -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 7B0D443ED8 for ; Mon, 16 Dec 2002 12:26:44 -0800 (PST) (envelope-from vjardin@wanadoo.fr) Received: from mel-rta6.wanadoo.fr (193.252.19.26) by mel-rto4.wanadoo.fr (6.7.015) id 3DF632EE003E29FA for freebsd-net@freebsd.org; Mon, 16 Dec 2002 21:26:43 +0100 Received: from there (217.128.244.14) by mel-rta6.wanadoo.fr (6.7.015) id 3DF62DBD0032C2ED for freebsd-net@freebsd.org; Mon, 16 Dec 2002 21:26:43 +0100 Message-ID: <3DF62DBD0032C2ED@mel-rta6.wanadoo.fr> (added by postmaster@wanadoo.fr) Content-Type: text/plain; charset="iso-8859-15" From: Vincent Jardin To: freebsd-net@freebsd.org Subject: Recursive encapsulation could panic the Kernel Date: Mon, 16 Dec 2002 21:45:08 +0100 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 Hi, With FreeBSD, there are many ways to create a recursive local encapsulation loop within the IPv4 and IPv6 stack. For example, this problem shows up when : - Netgraph with pptp is used or Netgraph with an ng_iface over UDP or any more complex Netgraph topologies... - gre interfaces - gif tunnels - ... There is a simple local solution that is used by gif_output() that is not protected by any mutex: /* * gif may cause infinite recursion calls when misconfigured. * We'll prevent this by introducing upper limit. * XXX: this mechanism may introduce another problem about * mutual exclusion of the variable CALLED, especially if we * use kernel thread. */ if (++called > max_gif_nesting) { log(LOG_NOTICE, "gif_output: recursively called too many times(%d)\n", called); m_freem(m); error = EIO; /* is there better errno? */ goto end; } I am wondering if a more generic solution could be found, however I do not have any idea yet ;-( I mean, is it possible to protect the kernel against any panic that could come from a mis-configuration of the routing tables ? Regards, Vincent To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message