Correct the sanity test length calculation in nfsrv_readdirplus(): len is

being incremented by 4 bytes too few each time through the loop, which
allows more data into the mbuf chain that we really want. In the worst
case, when we're using 32K read/write sizes with a TCP client, this causes
readdirplus replies to sometimes exceed NFS_MAXPACKET which leads to a
panic. This problem cropped up for me using an IRIX 6.5.4 NFSv3 TCP client
with 32K read/write sizes, however supposedly it can be triggered by
WinNT NFS servers too. In theory, it can probably be triggered by any
NFS v3 implementation using TCP as long as it's using the maxiumum block
size.

Reviewed by: Matthew Dillon <dillon@backplane.com>
This commit is contained in:
Bill Paul 1999-07-29 21:42:57 +00:00
parent 66085eafa5
commit 9c9743b67b
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=49232
2 changed files with 4 additions and 4 deletions

View File

@ -34,7 +34,7 @@
* SUCH DAMAGE.
*
* @(#)nfs_serv.c 8.8 (Berkeley) 7/31/95
* $Id: nfs_serv.c,v 1.81 1999/07/17 18:43:46 phk Exp $
* $Id: nfs_serv.c,v 1.82 1999/07/28 08:20:49 alc Exp $
*/
/*
@ -3474,7 +3474,7 @@ nfsrv_readdirplus(nfsd, slp, procp, mrq)
* are calculated conservatively, including all
* XDR overheads.
*/
len += (7 * NFSX_UNSIGNED + nlen + rem + NFSX_V3FH +
len += (8 * NFSX_UNSIGNED + nlen + rem + NFSX_V3FH +
NFSX_V3POSTOPATTR);
dirlen += (6 * NFSX_UNSIGNED + nlen + rem);
if (len > cnt || dirlen > fullsiz) {

View File

@ -34,7 +34,7 @@
* SUCH DAMAGE.
*
* @(#)nfs_serv.c 8.8 (Berkeley) 7/31/95
* $Id: nfs_serv.c,v 1.81 1999/07/17 18:43:46 phk Exp $
* $Id: nfs_serv.c,v 1.82 1999/07/28 08:20:49 alc Exp $
*/
/*
@ -3474,7 +3474,7 @@ nfsrv_readdirplus(nfsd, slp, procp, mrq)
* are calculated conservatively, including all
* XDR overheads.
*/
len += (7 * NFSX_UNSIGNED + nlen + rem + NFSX_V3FH +
len += (8 * NFSX_UNSIGNED + nlen + rem + NFSX_V3FH +
NFSX_V3POSTOPATTR);
dirlen += (6 * NFSX_UNSIGNED + nlen + rem);
if (len > cnt || dirlen > fullsiz) {