memory corruption after "Fix race when checking i_size on direct i/o read"

memory corruption after "Fix race when checking i_size on direct i/o read"

[J. Bruce Fields]

I'm getting warnings about corruption of the kmalloc-32 slab on an nfs
server while running some regression tests.

A bisect lands on 9fe55eea7e4b444bafc42fa0000cc2d1d2847275 "Fix race
when checking i_size on direct i/o read".  Is there any known problem
here?

It doesn't reproduce immediately and it's possible I could have made a
mistake on the bisect.

I'll verify and try to narrow down the reproducer.

--b.

Re: memory corruption after "Fix race when checking i_size on direct i/o read"

[J. Bruce Fields]

On Sat, Feb 08, 2014 at 03:45:22PM -0500, bfields wrote:
> I'm getting warnings about corruption of the kmalloc-32 slab on an nfs
> server while running some regression tests.
> 
> A bisect lands on 9fe55eea7e4b444bafc42fa0000cc2d1d2847275 "Fix race
> when checking i_size on direct i/o read".  Is there any known problem
> here?
> 
> It doesn't reproduce immediately and it's possible I could have made a
> mistake on the bisect.

Argh, apologies, yes--I'm able to reproduce the corruption before that
commit.  I'll keep looking....

--b.

[PATCH] nfsd4: fix acl buffer overrun

[J. Bruce Fields]

From: "J. Bruce Fields" <bfields@redhat.com>

4ac7249ea5a0ceef9f8269f63f33cc873c3fac61 "nfsd: use get_acl and
->set_acl" forgets to set the size in the case get_acl() succeeds, so
_posix_to_nfsv4_one() can then write past the end of its allocation.
Symptoms were slab corruption warnings.

Also, some minor cleanup while we're here.  (Among other things, note
that the first few lines guarantee that pacl is non-NULL.)

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
---
 fs/nfsd/nfs4acl.c |    9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

On Sat, Feb 08, 2014 at 09:09:33PM -0500, J. Bruce Fields wrote:
> On Sat, Feb 08, 2014 at 03:45:22PM -0500, bfields wrote:
> > I'm getting warnings about corruption of the kmalloc-32 slab on an nfs
> > server while running some regression tests.
> > 
> > A bisect lands on 9fe55eea7e4b444bafc42fa0000cc2d1d2847275 "Fix race
> > when checking i_size on direct i/o read".  Is there any known problem
> > here?
> > 
> > It doesn't reproduce immediately and it's possible I could have made a
> > mistake on the bisect.
> 
> Argh, apologies, yes--I'm able to reproduce the corruption before that
> commit.  I'll keep looking....

Fortunately my mistake was at the end of the bisect so the offending
commit was nearby (and clearly labeled "nfsd:...").  This fixes the
regression I was seeing.  I intend to include it in a pull request for
3.14 soon.

diff --git a/fs/nfsd/nfs4acl.c b/fs/nfsd/nfs4acl.c
index d3a5871..d190e33 100644
--- a/fs/nfsd/nfs4acl.c
+++ b/fs/nfsd/nfs4acl.c
@@ -151,17 +151,15 @@ nfsd4_get_nfs4_acl(struct svc_rqst *rqstp, struct dentry *dentry,
 		pacl = posix_acl_from_mode(inode->i_mode, GFP_KERNEL);
 		if (IS_ERR(pacl))
 			return PTR_ERR(pacl);
-		/* allocate for worst case: one (deny, allow) pair each: */
-		size += 2 * pacl->a_count;
 	}
+	/* allocate for worst case: one (deny, allow) pair each: */
+	size += 2 * pacl->a_count;
 
 	if (S_ISDIR(inode->i_mode)) {
 		flags = NFS4_ACL_DIR;
 		dpacl = get_acl(inode, ACL_TYPE_DEFAULT);
 		if (dpacl)
 			size += 2 * dpacl->a_count;
-	} else {
-		dpacl = NULL;
 	}
 
 	*acl = nfs4_acl_new(size);
@@ -170,8 +168,7 @@ nfsd4_get_nfs4_acl(struct svc_rqst *rqstp, struct dentry *dentry,
 		goto out;
 	}
 
-	if (pacl)
-		_posix_to_nfsv4_one(pacl, *acl, flags & ~NFS4_ACL_TYPE_DEFAULT);
+	_posix_to_nfsv4_one(pacl, *acl, flags & ~NFS4_ACL_TYPE_DEFAULT);
 
 	if (dpacl)
 		_posix_to_nfsv4_one(dpacl, *acl, flags | NFS4_ACL_TYPE_DEFAULT);
-- 
1.7.9.5

Re: [PATCH] nfsd4: fix acl buffer overrun

[Christoph Hellwig]

Looks good and sorry for the regression.

Re: [PATCH] nfsd4: fix acl buffer overrun

[J. Bruce Fields]

On Tue, Feb 11, 2014 at 12:25:48PM -0800, Christoph Hellwig wrote:
> Looks good and sorry for the regression.

Well, my fault for not reviewing the patch, I saw it and didn't give it
more than a skim.  Not sure I would have caught that, though.

The only thing I can think of that might have made it easier to catch
was breaking up the patch (v4 could probably have been done separately
from v2/v3?).  But I still probably would've overlooked it....

--b.