This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Sat Apr 20 01:34:28 2024 Received: from spaans.ds9a.nl (adsl-xs4all.ds9a.nl [213.84.159.51]) by kylie.puddingonline.com (8.11.6/8.11.6) with SMTP id g8IFDmX11030 for ; Wed, 18 Sep 2002 17:13:49 +0200 Received: (qmail 10206 invoked from network); 18 Sep 2002 06:58:42 -0000 Received: from unknown (HELO spaans.ds9a.nl) (3ffe:8280:10:360:202:44ff:fe2a:a1dd) by mayo.ipv6.ds9a.nl with SMTP; 18 Sep 2002 06:58:42 -0000 Received: (qmail 20206 invoked by uid 1000); 17 Sep 2002 20:33:03 -0000 Received: (maildatabase); juh Received: (qmail 8743 invoked by alias); 13 Oct 2001 19:52:55 -0000 Received: (qmail 8656 invoked from network); 13 Oct 2001 19:52:51 -0000 Received: from digger.ds9a.nl (HELO outpost.powerdns.com) (postfix@213.244.168.211) by spaans.ds9a.nl with SMTP; 13 Oct 2001 19:52:51 -0000 Received: from vvtp.nl (vvtp.tn.tudelft.nl [130.161.252.29]) by outpost.powerdns.com (Postfix) with SMTP id 1BB6AC6477 for ; Sat, 13 Oct 2001 20:52:53 +0200 (CEST) Received: (qmail 20737 invoked by uid 2547); 13 Oct 2001 18:52:45 -0000 Received: (qmail 20652 invoked from network); 13 Oct 2001 18:52:44 -0000 Received: from vger.kernel.org (199.183.24.194) by vvtp.tn.tudelft.nl with SMTP; 13 Oct 2001 18:52:44 -0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 13 Oct 2001 14:50:36 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 13 Oct 2001 14:50:27 -0400 Received: from ip122-15.asiaonline.net ([202.85.122.15]:22188 "EHLO uranus.planet.rcn.com.hk") by vger.kernel.org with ESMTP id ; Sat, 13 Oct 2001 14:50:06 -0400 Received: from rcn.com.hk (IDENT:davidtl@uranus.planet.rcn.com.hk [192.168.1.7]) by uranus.planet.rcn.com.hk (8.11.2/8.8.7) with ESMTP id f9DIhHM04786; Sun, 14 Oct 2001 02:43:17 +0800 Message-Id: <3BC88B44.E461CB63@rcn.com.hk> Date: Sun, 14 Oct 2001 02:43:16 +0800 From: David Chow Organization: Resources Computer Network Ltd. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2smp i686) X-Accept-Language: zh_TW, en Mime-Version: 1.0 To: Andreas Schwab Cc: linux-kernel@vger.kernel.org, nfs-devel@linux.kernel.org, nfs@lists.sourceforge.net Subject: Re: [PATCH] NFSv3 symlink bug References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) Not just that. the call to vfs_symlink on an NFS v3 mounted filesystem, the dentry that passed to vfs_symlink did not result with an inode member it remains null. This also lead to problem in the dcache and didn't have a d_instantiate() and d_add() in the nfs_symlink() . I have proved this is a bug. in kernel version 2.4.0 up to 2.4.10 . Not tested with 2.4.12 and 2.4.11 . This will not affect most of the process context calls, since after creating a symlink on the filesystem, because the dentry is not valid in the dcache, the call to the created link will result in a subsequent inode_lookup(). This will affect the performance a little bit but this bug voids the VFS standard. We are developing kernel modules that have file system operations, we are get stucked when using the NFS . NFS maintainers please help or at least acknowledge or otherwise we will start bug fix the code. Thanks. regards, David Chow (DC) Andreas Schwab wrote: > > The NFSv3 server in the 2.4.10 kernel has a bug in the symlink > implementation. The target pathname of the symlink is not necessarily > zero terminated when passed to vfs_symlink. This does not happen with > NFSv2, because it explicitly zero terminates the string when decoding it > from XDR (xdr_decode_string does this), but NFSv3 uses > xdr_decode_string_inplace. As a result you may get a spurious > ENAMETOOLONG when trying to create a symbolic link on a NFSv3 mounted > filesystem (if the length of the target path is a multiple of four). If > you don't get an error the created symlink will have random characters > appended, which exposes kernel memory to user space (that's why it's a > security problem). > > This patch changes the NFSv3 xdr function to use xdr_decode_string for the > symlink target, which seems to be the easiest solution. I also considered > adding an additional parameter to vfs_symlink to pass the length, but that > requires changes in each and every filesystem and changes the VFS API. > That could be a task for 2.5.x. > > --- linux/fs/nfsd/nfs3xdr.c.~1~ Fri Sep 21 06:02:01 2001 > +++ linux/fs/nfsd/nfs3xdr.c Tue Oct 2 16:12:27 2001 > @@ -99,7 +99,11 @@ > char *name; > int i; > > - if ((p = xdr_decode_string_inplace(p, namp, lenp, NFS3_MAXPATHLEN)) != NULL) { > + /* > + * Cannot use xdr_decode_string_inplace here, the name must be > + * zero terminated for vfs_symlink. > + */ > + if ((p = xdr_decode_string(p, namp, lenp, NFS3_MAXPATHLEN)) != NULL) { > for (i = 0, name = *namp; i < *lenp; i++, name++) { > if (*name == '\0') > return NULL; > > Andreas. > > -- > Andreas Schwab "And now for something > Andreas.Schwab@suse.de completely different." > SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg > Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/  - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/