From owner-freebsd-current  Tue Apr 17 13:37:40 2001
Delivered-To: freebsd-current@freebsd.org
Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131])
	by hub.freebsd.org (Postfix) with ESMTP
	id 682CB37B43F; Tue, 17 Apr 2001 13:37:32 -0700 (PDT)
	(envelope-from tlambert@usr09.primenet.com)
Received: (from daemon@localhost)
	by smtp01.primenet.com (8.9.3/8.9.3) id NAA17079;
	Tue, 17 Apr 2001 13:35:57 -0700 (MST)
Received: from usr09.primenet.com(206.165.6.209)
 via SMTP by smtp01.primenet.com, id smtpdAAAZraadH; Tue Apr 17 13:35:39 2001
Received: (from tlambert@localhost)
	by usr09.primenet.com (8.8.5/8.8.5) id NAA27919;
	Tue, 17 Apr 2001 13:37:32 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <200104172037.NAA27919@usr09.primenet.com>
Subject: BAD BUG: Second try
To: current@freeBSD.org
Date: Tue, 17 Apr 2001 20:37:32 +0000 (GMT)
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Oops.

NOTE: I don't follow this lists for weeks at a time, so please
include me directly in any responses.  Thanks.

Matt Dillon was looking at this, but I haven't heard from him
for a while on it.

Here is a patch to make it panic, instead of really, really
trashing memory (ignore the version, I'm using a vendor import
locally); the patch is to "crfree() and should be obvious:

===================================================================
diff -c -r1.2 kern_prot.c
*** kern/kern_prot.c	2001/03/21 02:33:03	1.2
--- kern/kern_prot.c	2001/04/17 02:22:48
***************
*** 1001,1006 ****
--- 1001,1009 ----
      int s;
      
      s = splhigh();
+ 	if ( cr->cr_ref == 0) {
+ 		panic("Freeing already free credential!\n");
+ 	}
  	if (--cr->cr_ref == 0) {
  		/*
  		 * Some callers of crget(), such as nfs_statfs(),
===================================================================


Unfortunately, There's also a nameidata structure (it's the
only data structure that's exactly 72 bytes long, which I was
able to determine by printing sizeof() information for all
kernel structures, and gre'ping for "72") getting freed and
then either continued to be used, or being used as a result
of an unchecked allocation failure (I'm still looking for
that one).

Basically, the second causes invariants to whine about data
modified on the freelist to my console, while the first one
results in an eventual panic dues to spammed memory (for the
obvious reason that you can't free the same thing twice).

The problems only become obvious when you open and then close
around 30,000 TCP connections; sometimes it takes a couple of
tries before it panics your machine.

I have some programs that demonstrate the bug, if anyone is
interested in repeating it on their machines locally (you will
need appropriate open file limits and bump up to 40,000 or so
net.inet.ip.portrange.last, e.g.:

	sysctl -w net.inet.ip.portrange.last=45000

Which means your box will need about a gig of memory.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message