Skip site navigation (1)Skip section navigation (2) 
Date:      Thu, 19 Dec 2002 09:28:05 +0100
From:      Lars Eggert <larse@ISI.EDU>
To:        Vincent Jardin <vjardin@wanadoo.fr>
Cc:        freebsd-net@freebsd.org
Subject:   Re: Recursive encapsulation could panic the Kernel
Message-ID:  <3E018315.5070602@isi.edu>
In-Reply-To: <3DF62DBD0032C2ED@mel-rta6.wanadoo.fr> (added by postmaster@wanadoo.fr)
References:  <3DF62DBD0032C2ED@mel-rta6.wanadoo.fr> (added by postmaster@wanadoo.fr)
next in thread | previous in thread | raw e-mail | index | archive | help 

[-- Attachment #1 --]
On 12/16/2002 9:45 PM, Vincent Jardin wrote:
> 
> With FreeBSD, there are many ways to create a recursive local encapsulation 
> loop within the IPv4 and IPv6 stack.
...
> There is a simple local solution that is used by gif_output() that is not 
> protected by any mutex:
..
> 	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 ;-(

There are legitimate reasons for wanting recursive encapsulation, e.g. 
virtual networks inside virtual networks. (One man's bug is another 
man's feature...)

Recursive encapsulation itself is actually fine: at some point you'll 
run out of packet space, and the packet is dropped.

The problem is with *implementing* recursive encapsulation recursively, 
as this can overflow the kernel stack and cause crashes. The fix that 
I'd prefer would prevent this stack overflow from happening, without 
limiting recursive encapsulation.

But I'd settle for any patch that comes with a knob to turn it off.

Lars
-- 
Lars Eggert <larse@isi.edu>           USC Information Sciences Institute

[-- Attachment #2 --]
0	*H
010	+0	*H
	080fErtcvE.0
	*H
010	UZA10UWestern Cape10U	Cape Town10U
Thawte Consulting1(0&UCertification Services Division1$0"UThawte Personal Freemail CA1+0)	*H
	personal-freemail@thawte.com0
000830000000Z
040827235959Z010	UZA10UWestern Cape10U	Cape Town10
U
Thawte10UCertificate Services1(0&UPersonal Freemail RSA 2000.8.3000
	*H
032c	%E>nx'gڈD)c5*mp<ܮto034qmOe
KaU5u'rװ|CBPQ<9TIf-	kiN0L0)U"0 010UPrivateLabel1-2970U00U0
	*H
1KG]qSl]y=&b""I'{9$
*8PUl
LGlX1B	li+@]jy.%݊
Z<D&iHΥbb090%A0
	*H
010	UZA10UWestern Cape10U	Cape Town10
U
Thawte10UCertificate Services1(0&UPersonal Freemail RSA 2000.8.300
020824185339Z
030824185339Z0T10
UEggert1
0U*Lars10ULars Eggert10	*H
	
larse@isi.edu0"0
	*H
0
6Fxΰ7aED&0+Dj)ֽXCUcnleijmz~S0JjWV~	1^({IݛLjӖ
ao:bP}WLVܱ욗cDɖ_Kv.A(W49;Z8-uXE
6b
@_0%#d`Rto5 L0R`w@7
r	Hcc	U3%7N_oV0T0*+e!000L2uMyffBNUbNJJcdZ2s0U0
larse@isi.edu0U00
	*H
]Ȕ,fK<cjRZeLan@Z6,=
fK?yO#8+	Ni*LSfpQg<(aӒ$kTx_AL1>ގ|S090%A0
	*H
010	UZA10UWestern Cape10U	Cape Town10
U
Thawte10UCertificate Services1(0&UPersonal Freemail RSA 2000.8.300
020824185339Z
030824185339Z0T10
UEggert1
0U*Lars10ULars Eggert10	*H
	
larse@isi.edu0"0
	*H
0
6Fxΰ7aED&0+Dj)ֽXCUcnleijmz~S0JjWV~	1^({IݛLjӖ
ao:bP}WLVܱ욗cDɖ_Kv.A(W49;Z8-uXE
6b
@_0%#d`Rto5 L0R`w@7
r	Hcc	U3%7N_oV0T0*+e!000L2uMyffBNUbNJJcdZ2s0U0
larse@isi.edu0U00
	*H
]Ȕ,fK<cjRZeLan@Z6,=
fK?yO#8+	Ni*LSfpQg<(aӒ$kTx_AL1>ގ|S100010	UZA10UWestern Cape10U	Cape Town10
U
Thawte10UCertificate Services1(0&UPersonal Freemail RSA 2000.8.30%A0	+0	*H
	1	*H
0	*H
	1
021219082805Z0#	*H
	1ݲ6ڝܗf>\0R	*H
	1E0C0
*H
0*H
0
*H
@0+0
*H
(0	+710010	UZA10UWestern Cape10U	Cape Town10
U
Thawte10UCertificate Services1(0&UPersonal Freemail RSA 2000.8.30%A0*H
	1010	UZA10UWestern Cape10U	Cape Town10
U
Thawte10UCertificate Services1(0&UPersonal Freemail RSA 2000.8.30%A0
	*H
Y[ӷ@8W\c۽zrÎZ'~CQvl_ۓ.وi;u&2SspvBWI9%fMJʗpH!I :clLcӣA\7xĥh.ZD\C͡[vEmAT+lpU3]9.ϟH]Up<h?ZN'i9K0[ыn$Nss"y 6_#

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E018315.5070602>