On Sun, Jan 18, 2015 at 7:29 AM, Junxiao Bi <junxiao.bi@xxxxxxxxxx> wrote: > > nfsd4_decode_open() doesn't initialize variable open->op_file and > open->op_stp, they are initialized in nfsd4_process_open1(), but if > any error happens before initializing them, nfsd4_open() will call > into nfsd4_cleanup_open_state() and corrupt the memory. > > Since nfsd4_process_open1() will initialize these two variables and > open->op_openowner, make them default to null at the beginning. > > Signed-off-by: Junxiao Bi <junxiao.bi@xxxxxxxxxx> > --- > fs/nfsd/nfs4state.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c > index c06a1ba..6e74a91 100644 > --- a/fs/nfsd/nfs4state.c > +++ b/fs/nfsd/nfs4state.c > @@ -3547,6 +3547,10 @@ nfsd4_process_open1(struct nfsd4_compound_state *cstate, > struct nfs4_openowner *oo = NULL; > __be32 status; > > + open->op_file = NULL; > + open->op_openowner = NULL; > + open->op_stp = NULL; > + > if (STALE_CLIENTID(&open->op_clientid, nn)) > return nfserr_stale_clientid; > /* Have you ever seen an instance of this corruption? I would have thought that the kzalloc() in nfsd4_decode_compound() and/or the earlier memset() in svc_process_common() would ensure that these fields are always initialised to NULL. Cheers Trond -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx -- 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
