[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.021 / U:7.292 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site