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

>Peter Staubach <staubach@redhat.com> 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.

ps
-
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/

\
 
 \ /
  Last update: 2005-09-14 21:04    [from the cache]
©2003-2011 Jasper Spaans