[net.bugs.uucp] Yet another uucp bug

jsm@uvacs.UUCP (01/03/84)

This bug is in both the 4.2BSD and System V versions of uucp, and  probably
most  other  versions (Actually I can't swear to 4.2BSD since we don't have
it yet, but we run a version of rtiuucp which is only about 1  month  older
than the version that made it to the 4.2 Distribution).

     This bug causes uucico to get a segmentation fault and dump core  (via
intrEXIT() and abort()).  In file pk1.c, procedure pkgetpack, you will find
this fragment of code (line 186 in our version):

		bp = pk->p_ipool;
		pk->p_ipool = (char **) *bp;   <<<<<This is the killer
		if (bp == NULL) {
			PKDEBUG(7, "bp NULL %s\n", "");
		return;
		}

     Basically, whats going on here is that a pool of  linked  buffers  are
being  traversed.  Both  bp and pk->p_ipool are declared as (char **).  The
first 4 bytes of each buffer is used as a pointer to the next  buffer  when
the buffer is on the free list(pk->p_ipool).  When pk->p_ipool is NULL then
there are no buffers left.  However the test for NULL  is  not  done  until
after  another attempt at link traversal has been done.  If pk->p_ipool was
NULL(0) when this fragment was reached, it will now be (On a VAX) 0x8c20000
(If  bp=0 then *bp will contain the first 4 bytes of the text segment which
is the C startup(crt0.o)).

     At this point, the free list is trashed, the test  for  NULL  succeeds
and  pkgetpack  returns.  Buffers  can be put back on the free list with no
problem, however the last pointer will  remain  0x8c20000.  Eventually,  if
this fragment gets run again with no buffers available, then bp will be set
to 0x8c20000 and when the reference to  *bp  is  hit:  Voila!  Segmentation
fault.

     It's fairly simple to fix; just put the test before the indirection on
bp (replace the above fragment with):

		if ((bp = pk->p_ipool) == NULL) {
			PKDEBUG(7, "bp NULL %s\n", "");
			return;
		}
		pk->p_ipool = (char **) *bp;


     I can't tell you what conditions are necessary to reach this point  (I
didn't  have  the time to dig that deep.  Maybe lauren@vortex can tell us),
but it doesn't happen very often.

			John S. Marvin
		UUCP:   {duke,ihnp4}!mcnc!uvacs!jsm
		CSNET:  jsm@virginia
		ARPA:   jsm.virginia@csnet-relay