Date: Thu, 3 Nov 2011 13:07:52 +0100 From: Kristof Provost <kristof@sigsegv.be> To: prabhakar lakhera <prabhakar.lakhera@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: mbuf leak in icmp6 code?? Message-ID: <20111103120752.GG9553@thebe.jupiter.sigsegv.be> In-Reply-To: <CALg%2BrhV-PcA2BJ2KcMd8KrHWN%2BrzpLu4QTC6aZL6UbUX23ebkA@mail.gmail.com> References: <CALg%2BrhV-PcA2BJ2KcMd8KrHWN%2BrzpLu4QTC6aZL6UbUX23ebkA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2011-11-01 14:27:13 (-0700), prabhakar lakhera <prabhakar.lakhera@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111103120752.GG9553>