NFSD: Don't hold unrefcounted creds over call to nfsd_setuser()

From: J. Bruce Fields
Date: Fri Jul 03 2009 - 11:48:21 EST


The following patch is appropriate for 2.6.31 (and stable), and is also
available from

git://linux-nfs.org/~bfields/linux.git for-2.6.31

--b.

commit 033a666ccb842ab4134fcd0c861d5ba9f5d6bf3a
Author: David Howells <dhowells@xxxxxxxxxx>
Date: Thu Jul 2 14:35:32 2009 +0100

NFSD: Don't hold unrefcounted creds over call to nfsd_setuser()

nfsd_open() gets an unrefcounted pointer to the current process's effective
credentials at the top of the function, then calls nfsd_setuser() via
fh_verify() - which may replace and destroy the current process's effective
credentials - and then passes the unrefcounted pointer to dentry_open() - but
the credentials may have been destroyed by this point.

Instead, the value from current_cred() should be passed directly to
dentry_open() as one of its arguments, rather than being cached in a variable.

Possibly fh_verify() should return the creds to use.

This is a regression introduced by
745ca2475a6ac596e3d8d37c2759c0fbe2586227 "CRED: Pass credentials through
dentry_open()".

Signed-off-by: David Howells <dhowells@xxxxxxxxxx>
Tested-and-Verified-By: Steve Dickson <steved@xxxxxxxxxx>
Cc: stable@xxxxxxxxxx
Signed-off-by: J. Bruce Fields <bfields@xxxxxxxxxxxxxx>

diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 4145083..23341c1 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -678,7 +678,6 @@ __be32
nfsd_open(struct svc_rqst *rqstp, struct svc_fh *fhp, int type,
int access, struct file **filp)
{
- const struct cred *cred = current_cred();
struct dentry *dentry;
struct inode *inode;
int flags = O_RDONLY|O_LARGEFILE;
@@ -733,7 +732,7 @@ nfsd_open(struct svc_rqst *rqstp, struct svc_fh *fhp, int type,
vfs_dq_init(inode);
}
*filp = dentry_open(dget(dentry), mntget(fhp->fh_export->ex_path.mnt),
- flags, cred);
+ flags, current_cred());
if (IS_ERR(*filp))
host_err = PTR_ERR(*filp);
else
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/