From owner-freebsd-hackers Sat Nov 23 18:51:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA24215 for hackers-outgoing; Sat, 23 Nov 1996 18:51:18 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA24204 for ; Sat, 23 Nov 1996 18:51:15 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16194(2)>; Sat, 23 Nov 1996 18:50:41 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177557>; Sat, 23 Nov 1996 18:50:34 -0800 To: Tom Samplonius cc: Jaye Mathisen , hackers@freebsd.org Subject: Re: Has anybody addressed this "ping" problem? Is it even an issue with FreeBSD? In-reply-to: Your message of "Fri, 22 Nov 96 20:06:21 PST." Date: Sat, 23 Nov 1996 18:50:25 PST From: Bill Fenner Message-Id: <96Nov23.185034pst.177557@crevenia.parc.xerox.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message you write: > The BSD codebase has always been free of this bug (well I can't actually >speak about pre-4.3 versions, but I doubt any still exist). That's not very true. You could never crash BSD with a 64k+ packet because BSD has always had signedness bugs that causes it to be unable to reassemble packets greater than 32k. However, many BSD's are vulnerable to the equivalent 32k+ packet. SunOS is not vulnerable to 32k+ packets because of a signed compare with the MTU (Oooh, this 32769 byte packet is smaller than the 1500 byte MTU, I'll send it directly) and luckily the network drivers are sufficiently robust to not fail when handed a ridiculously-sized packet to send. NeXTStep (about as 4.3-bsd as you can get) is vulnerable to 32k+ packets. NetBSD 1.1 is as well. The only reason FreeBSD is not vulnerable to this problem is because of a signed/unsigned bug in the check to see if the packet will fit into the interface queue (a check no other BSD has). So, to answer Jaye's original question, yes, someone has looked into it in some detail =) Bill