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
                                        [EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to