Re: 2.4.10 - knfsd symlink corruption

[Neil Brown]

On Tuesday September 25, [e-mail] wrote:
> Under 2.4.10, I can mount an exported directory to another machine (or
> loopback to the localhost), and while creating symlinks some will end
> up with corrupt destinations.  It looks like random binary garbage is
> being appended to the end of the file name.

Oh dear, dear, dear.  That was careless wasn't it....

In fs/nfsd/nfs3xdr.c
 in decode_pathname
  change "xdr_decode_string_inplace" to "xdr_decode_string".

This won't affect NFSv2, only v3.

I would like to use the "_inplace" version, but "vfs_symlink" doesn't
take a length argument for the symlink, and _inplace cannot nul
terminate. 

NeilBrown

> 
> Normal files seem to be copied and created just fine, but symlinks end
> up with massive corruption in the name of the file they point to (I
> haven't tried checksumming files after copying, though).
> 
> This happens while using 2.4.10 as the nfs server.  Tested with both
> 2.4.2-12 (RH 7.1 stock) and 2.4.10 as client.  The problem doesn't
> show with the stock RH kernel on the server.
> 
> It seems to help if you pick a long file name to link to (ln -s
> /usr/IBMdb2/V7.1/instance foo   is much more likely to trip the bug than
> ln -s /dev/null foo) and sometimes it seems that repeating links to
> the same file can get more of the links to create successfully.
> 
> I'll attach an example of triggering the bug (I suspect all the binary
> involved will trip up MTA's without some encoding).
> 
> Both the nfs server and client in this case are dual proc Xeon 700's
> w/ 4gig of RAM.  The actual directory being nfs exported is mounted on
> an internal scsi drive.
> 
> I'll be happy to try out any patches or provide access to test boxes
> if it'll help track things down.
> 
> 
> Erik 
>