]> git.proxmox.com Git - mirror_ubuntu-zesty-kernel.git/commitdiff
nfsd4: zero op arguments beyond the 8th compound op
authorJ. Bruce Fields <bfields@redhat.com>
Thu, 17 Jul 2014 20:20:39 +0000 (16:20 -0400)
committerJ. Bruce Fields <bfields@redhat.com>
Thu, 17 Jul 2014 20:20:39 +0000 (16:20 -0400)
The first 8 ops of the compound are zeroed since they're a part of the
argument that's zeroed by the

memset(rqstp->rq_argp, 0, procp->pc_argsize);

in svc_process_common().  But we handle larger compounds by allocating
the memory on the fly in nfsd4_decode_compound().  Other than code
recently fixed by 01529e3f8179 "NFSD: Fix memory leak in encoding denied
lock", I don't know of any examples of code depending on this
initialization. But it definitely seems possible, and I'd rather be
safe.

Compounds this long are unusual so I'm much more worried about failure
in this poorly tested cases than about an insignificant performance hit.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
fs/nfsd/nfs4xdr.c

index 01023a5951632326a42fdc352352bc12754527e6..628b430e743e470ae772f09af7b33574ba0471b2 100644 (file)
@@ -1635,7 +1635,7 @@ nfsd4_decode_compound(struct nfsd4_compoundargs *argp)
                goto xdr_error;
 
        if (argp->opcnt > ARRAY_SIZE(argp->iops)) {
-               argp->ops = kmalloc(argp->opcnt * sizeof(*argp->ops), GFP_KERNEL);
+               argp->ops = kzalloc(argp->opcnt * sizeof(*argp->ops), GFP_KERNEL);
                if (!argp->ops) {
                        argp->ops = argp->iops;
                        dprintk("nfsd: couldn't allocate room for COMPOUND\n");