Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!mordor!lll-tis!ames!ucbcad!ucbvax!LANL.GOV!cpw%sneezy
From: cpw%sneezy@LANL.GOV (C. Philip Wood)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Reassembly queues in TCP
Message-ID: <8706302212.AA01092@sneezy.lanl.gov>
Date: Tue, 30-Jun-87 18:12:08 EDT
Article-I.D.: sneezy.8706302212.AA01092
Posted: Tue Jun 30 18:12:08 1987
Date-Received: Thu, 2-Jul-87 01:24:32 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 17

About a month ago I posted some commentary on a Berkeley UNIX panic caused
by an uncontrolled stream of 1 byte TCP packets emanating from some VMS
hosts.  I had also posted a fix to UNIX-wizards.  Unfortunately, that
was not the complete story.  We continued to crash occasionally due to
a clobbered message buffer pool.  The reason for this has been found.

4.3 BSD has a cluster buffer concept which is used in socket creation
among other things.  A cluster buffer is relatively large block of
storage (CLBYTES bytes) pointed to in mysterious ways by the normal
small message buffers.
The routine to get a cluster buffer (MCLGET) did not set up an error
condition if it failed to reserve a cluster buffer.  Consequently, 
at some point after running out of message buffers, the system would
run across one of the clobbered cluster buffers and panic.

The fix to MCLGET is to set the 'm_len' field in the small message buffer
to 0 or anything other than CLBYTES before returning to the caller.