From owner-cvs-src@FreeBSD.ORG  Thu Oct 16 12:09:09 2003
Return-Path: <owner-cvs-src@FreeBSD.ORG>
Delivered-To: cvs-src@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id D136716A4BF
	for <cvs-src@FreeBSD.org>; Thu, 16 Oct 2003 12:09:09 -0700 (PDT)
Received: from rootlabs.com (root.org [67.118.192.226])
	by mx1.FreeBSD.org (Postfix) with SMTP id 353C843FE3
	for <cvs-src@FreeBSD.org>; Thu, 16 Oct 2003 12:09:08 -0700 (PDT)
	(envelope-from nate@rootlabs.com)
Received: (qmail 38324 invoked by uid 1000); 16 Oct 2003 19:09:09 -0000
Date: Thu, 16 Oct 2003 12:09:09 -0700 (PDT)
From: Nate Lawson <nate@root.org>
To: John Baldwin <jhb@FreeBSD.org>
In-Reply-To: <XFMail.20031016143026.jhb@FreeBSD.org>
Message-ID: <20031016115801.S38049@root.org>
References: <XFMail.20031016143026.jhb@FreeBSD.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: cvs-src@FreeBSD.org
cc: src-committers@FreeBSD.org
cc: cvs-all@FreeBSD.org
Subject: RE: cvs commit: src/sys/netinet ip_fw2.c
X-BeenThere: cvs-src@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Oct 2003 19:09:09 -0000

On Thu, 16 Oct 2003, John Baldwin wrote:
> On 16-Oct-2003 Kirk McKusick wrote:
> >   Modified files:
> >     sys/netinet          ip_fw2.c
> >   Log:
> >   Malloc buckets of size 128 have been having their 64-byte offset
> >   trashed after being freed. This has caused several panics including
> >   kern/42277 related to soft updates. Jim Kuhn tracked the problem
> >   down to ipfw limit rule processing.  In the expiry of dynamic rules,
> >   it is possible for an O_LIMIT_PARENT rule to be removed when it still
> >   has live children.  When the children eventually do expire, a pointer
> >   to the (long gone) parent is dereferenced and a count decremented.
> >   Since this memory can, and is, allocated for other purposes (in the
> >   case of kern/42277 an inodedep structure), chaos ensues. The offset
> >   in question in inodedep is the offset of the 16 bit count field in
> >   the ipfw2 ipfw_dyn_rule.
> >
> >   Submitted by:   Jim Kuhn <jkuhn@sandvine.com>
> >   Reviewed by:    "Evgueni V. Gavrilov" <aquatique@rusunix.org>
> >   Reviewed by:    Ben Pfountz <netprince@vt.edu>
> >   MFC after:      1 week
>
> Wow, impressive find!

I agree, but this is also aggravating.  We need more maintainers hunting
down their own problems.  This problem was found in -stable and has been
around for at least 14 months.  I believe options INVARIANTS would have
shown this earlier via mtrash_ctor() (if the subsystem had been testing
under -current).

-Nate