From owner-cvs-all Tue Sep 29 15:33:19 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA25221 for cvs-all-outgoing; Tue, 29 Sep 1998 15:33:19 -0700 (PDT) (envelope-from owner-cvs-all) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA25197; Tue, 29 Sep 1998 15:33:11 -0700 (PDT) (envelope-from mckusick@FreeBSD.org) From: Kirk McKusick Received: (from mckusick@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id PAA23495; Tue, 29 Sep 1998 15:33:06 -0700 (PDT) Date: Tue, 29 Sep 1998 15:33:06 -0700 (PDT) Message-Id: <199809292233.PAA23495@freefall.freebsd.org> To: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: cvs commit: src/sys/nfs nfs_socket.c Sender: owner-cvs-all@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk mckusick 1998/09/29 15:33:06 PDT Modified files: sys/nfs nfs_socket.c Log: The code checks each fragment mark to see if it's valid; if the fragment is less than NFS_MINPACKET or greater than NFS_MAXPACKET in size, it barfs and, I think, drops the connection. However, there's no guarantee that in a multi-fragment RPC, all the fragments will be at least as large as NFS_MINPACKET. In fact, with the version of "tclnfs" we have here, which supports NFS over TCP, at least when built under SunOS 4.1.3 (i.e., with 4.1.3's user-mode ONC RPC library), I can *repeatably* cause "tclnfs" to send a request with more than one fragment, one of which is only 8 bytes long. I just do a 3877-byte write to a file, at an offset of 0. The check that "slp->ns_reclen" is greater than or equal to NFS_MINPACKET serves no useful purpose - if the NFS server code can't handle packets < NFS_MINPACKET bytes, it can't handle them over *any* protocol, so the check has to be done above the RPC-over-TCP layer - and should be removed. Obtained from: Fix from Guy Harris, forwarded by Rick Macklem. Revision Changes Path 1.46 +2 -2 src/sys/nfs/nfs_socket.c