From owner-freebsd-net@FreeBSD.ORG Thu Nov 3 12:07:55 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B3FE1065670 for ; Thu, 3 Nov 2011 12:07:55 +0000 (UTC) (envelope-from kp@sigsegv.be) Received: from mercury.codepro.be (mercury.codepro.be [IPv6:2001:4b98:dc0:51:216:3eff:feb7:3147]) by mx1.freebsd.org (Postfix) with ESMTP id 148108FC27 for ; Thu, 3 Nov 2011 12:07:55 +0000 (UTC) Received: from adrastea.jupiter.sigsegv.be (adrastea.jupiter.sigsegv.be [IPv6:2001:6f8:1498:1::3]) by mercury.codepro.be (Postfix) with ESMTP id 62A09361; Thu, 3 Nov 2011 13:07:53 +0100 (CET) Received: from thebe.jupiter.sigsegv.be (thebe.jupiter.sigsegv.be [172.16.1.5]) by adrastea.jupiter.sigsegv.be (Postfix) with ESMTP id CE9EF5953; Thu, 3 Nov 2011 13:07:52 +0100 (CET) Received: by thebe.jupiter.sigsegv.be (Postfix, from userid 1000) id A826525308; Thu, 3 Nov 2011 13:07:52 +0100 (CET) Date: Thu, 3 Nov 2011 13:07:52 +0100 From: Kristof Provost To: prabhakar lakhera Message-ID: <20111103120752.GG9553@thebe.jupiter.sigsegv.be> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org Subject: Re: mbuf leak in icmp6 code?? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 12:07:55 -0000 On 2011-11-01 14:27:13 (-0700), prabhakar lakhera wrote: > In FreeBSD icmp6 code I see function where we are either going to > freeit where passed mbuf is freed or we are simply returning. > For example: > > icmp6_input calls icmp6_redirect_input and right after it returns it > makes m=NULL. Inside icmp6_redirect_input there are checks for ifp and > for the message being short (which probably don't get exercised that > often (or at all?)) and for these checks simply return. Looks to be > mbuf leak. In other icmp6 functions also we have similar instances. The checks for m and ifp should probably be asserts, rather than just returns. I think they are always supposed to be true. You do have a point with the message length check, but that's only true if PULLDOWN_TEST is set. IP_EXTHDR_CHECK does free the mbuf is the message is too short. Regards, Kristof