On Thu, 17 Mar 2011 14:01:05 -0400 Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> wrote: > On Thu, 2011-03-17 at 09:38 +1100, NeilBrown wrote: > > We should probably submit a fix to 2.6.37-stable though. For that it > > is possibly simplest to tell xdr_decode_inline to round nbytes up to > > a multiple of 4 - would you agree? > > How about the following fix for 2.6.37 stable? That is good for NFSv3, but NFSv2 has the same problem. Code fragment is p = xdr_inline_decode(xdr, entry->len + 4); if (unlikely(!p)) goto out_overflow; entry->name = (const char *) p; p += XDR_QUADLEN(entry->len); entry->prev_cookie = entry->cookie; entry->cookie = ntohl(*p++); so again we have the cookie after the name and they are decoded together. This is what I have committed to openSUSE 11.3 for the next update. It may not match the long-term preferred direction, but it is simple and obviously covers all cases. NeilBrown From: NeilBrown <neilb@xxxxxxx> Subject: Fix cookie decoding problem in NFS Patch-mainline: no References: bnc#678123 nfs3proc decode_dirent asks xdr_inline_decode to return a name buffer and the cookie in a single request. There could be padding between these, but if xdr_inline_decode calls xdr_copy_to_scratch, it will assume the padding is at the end. So in xdr_copy_to_scratch, round up 'nbytes' to we make don't fail to return useful data. Acked-by: NeilBrown <neilb@xxxxxxx> Signed-off-by: Neil Brown <neilb@xxxxxxx> --- net/sunrpc/xdr.c | 5 +++++ 1 file changed, 5 insertions(+) --- linux-2.6.37-openSUSE-11.4.orig/net/sunrpc/xdr.c +++ linux-2.6.37-openSUSE-11.4/net/sunrpc/xdr.c @@ -673,6 +673,11 @@ static __be32 *xdr_copy_to_scratch(struc void *cpdest = xdr->scratch.iov_base; size_t cplen = (char *)xdr->end - (char *)xdr->p; + /* some callers assume we return the full rounded-up + * number of bytes. + */ + nbytes = XDR_QUADLEN(nbytes)*4; + if (nbytes > xdr->scratch.iov_len) return NULL; memcpy(cpdest, xdr->p, cplen); -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
