Gitweb:     http://git.kernel.org/linus/d953126a28f97ec965d23c69fd5795854c048f30
Commit:     d953126a28f97ec965d23c69fd5795854c048f30
Parent:     fccba8045537f7e840d0e7565e1989d465e488a3
Author:     Trond Myklebust <Trond.Myklebust@netapp.com>
AuthorDate: Tue Jul 21 19:22:38 2009 -0400
Committer:  Trond Myklebust <Trond.Myklebust@netapp.com>
CommitDate: Tue Jul 21 19:22:38 2009 -0400

    NFSv4: Fix a problem whereby a buggy server can oops the kernel
    
    We just had a case in which a buggy server occasionally returns the wrong
    attributes during an OPEN call. While the client does catch this sort of
    condition in nfs4_open_done(), and causes the nfs4_atomic_open() to return
    -EISDIR, the logic in nfs_atomic_lookup() is broken, since it causes a
    fallback to an ordinary lookup instead of just returning the error.
    
    When the buggy server then returns a regular file for the fallback lookup,
    the VFS allows the open, and bad things start to happen, since the open
    file doesn't have any associated NFSv4 state.
    
    The fix is firstly to return the EISDIR/ENOTDIR errors immediately, and
    secondly to ensure that we are always careful when dereferencing the
    nfs_open_context state pointer.
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
---
 fs/nfs/dir.c      |    2 +-
 fs/nfs/nfs4proc.c |   16 ++++++++++++----
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index 38d42c2..32062c3 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -1025,12 +1025,12 @@ static struct dentry *nfs_atomic_lookup(struct inode *dir, struct dentry *dentry
 				res = NULL;
 				goto out;
 			/* This turned out not to be a regular file */
-			case -EISDIR:
 			case -ENOTDIR:
 				goto no_open;
 			case -ELOOP:
 				if (!(nd->intent.open.flags & O_NOFOLLOW))
 					goto no_open;
+			/* case -EISDIR: */
 			/* case -EINVAL: */
 			default:
 				goto out;
diff --git a/fs/nfs/nfs4proc.c ...
[ message continues ]