[lkml]   [2005]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] nfs client, kernel 2.4.31: readlink result overflow
Assar wrote:

>Peter Staubach <> writes:
>>>Yes, but fs/nfs/nfs2xdr.c:nfs_xdr_readlinkres on 2.4.31 writes a 0 at
>>>the end of string after having received it, which is what started this
>>>thread. Look at the end of nfs_xdr_readlinkres.
>>Yes, I know that. For C purposes, the string must be null terminated.
>Then I'm sorry but I don't understand what your point was. Do you
>believe there's a bug in nfs_xdr_readlinkres and if so, how do you
>think it should work?

Yes, I think that there is a bug in the boundary checking. I think that:

if (len > rcvbuf->page_len)

should be

if (len >= rcvbuf->page_len - sizeof(u32) || len > 1024)

because the code puts the length in the first 4 bytes and then the
contents of the symbolic link is stored in the rest of the page.
The ">=" accounts for the null byte will be appended to the length.
The additional check for 1024 is due to the NFS Version 2 protocol
limiting the size of the contents of a symbolic link which can be
returned to 1024 bytes.

Also, the NFS Version 3, nfs3_xdr_readlinkres, is broken in the same
way and will need to be changed in the same fashion, except that
the NFS Version 3 protocol does not place an arbitrary limit on the
size of the contents of the symbolic which can be returned. The
comparison against 1024 won't be needed here.


The 2.6 kernel code is also broken, but in a different, but once again,
similar fashions.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-09-14 21:04    [W:0.042 / U:3.204 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site