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
[email protected] 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
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
> [email protected] 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>>>>> " " == David Chow <[email protected]> writes:
> 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
Wrong. Look again... We do instantiate NFSv3 symlinks.
> 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
The only bug I can see is if nfs_fhget() fails to allocate a new
inode. In that case we should drop the dentry. That should be a pretty
rare bug though and would only happen under extremely low memory
conditions.
Cheers,
Trond
--- linux-2.4.12/fs/nfs/dir.c.orig Tue Jun 12 20:15:08 2001
+++ linux-2.4.12/fs/nfs/dir.c Sat Oct 13 21:07:26 2001
@@ -928,6 +928,8 @@
&attr, &sym_fh, &sym_attr);
if (!error && sym_fh.size != 0 && (sym_attr.valid & NFS_ATTR_FATTR)) {
error = nfs_instantiate(dentry, &sym_fh, &sym_attr);
+ if (error)
+ d_drop(dentry);
} else {
if (error == -EEXIST)
printk("nfs_proc_symlink: %s/%s already exists??\n",