linux-kernel - Re: [PATCH 5/5] NFS: Correct the NFS mount path when following a referral

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 23 Jun 2009 15:42:02 -0500
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	Trond Myklebust <Trond.Myklebust@...app.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Al Viro <viro@...IV.linux.org.uk>,
	Christoph Hellwig <hch@...radead.org>,
	linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/5] NFS: Correct the NFS mount path when following a
	referral

Quoting Trond Myklebust (Trond.Myklebust@...app.com):
> Signed-off-by: Trond Myklebust <Trond.Myklebust@...app.com>
> ---
> 
>  fs/nfs/super.c |   24 ++++++++++++++++++++++++
>  1 files changed, 24 insertions(+), 0 deletions(-)
> 
> 
> diff --git a/fs/nfs/super.c b/fs/nfs/super.c
> index 8da7e59..daecbad 100644
> --- a/fs/nfs/super.c
> +++ b/fs/nfs/super.c
> @@ -2548,6 +2548,27 @@ static struct vfsmount *nfs_do_root_mount(struct file_system_type *fs_type,
>  	return root_mnt;
>  }
> 
> +static void nfs_fix_devname(const struct path *path, struct vfsmount *mnt)
> +{
> +	char *page = (char *) __get_free_page(GFP_KERNEL);
> +	char *devname, *tmp;
> +
> +	if (page == NULL)
> +		return;
> +	devname = nfs_path(path->mnt->mnt_devname,
> +			path->mnt->mnt_root, path->dentry,
> +			page, PAGE_SIZE);
> +	if (devname == NULL)
> +		goto out_freepage;
> +	tmp = kstrdup(devname, GFP_KERNEL);
> +	if (tmp == NULL)
> +		goto out_freepage;
> +	kfree(mnt->mnt_devname);
> +	mnt->mnt_devname = tmp;

(looking through patch 3 a bit) is this expected to be safe because all
callers will send in a mnt which was privately mounted as nfs root_mnt through
vfs_kern_mount?  So that at this point noone else can have a ref to
mnt?

If that isn't the intent, then this seems problematic...  (If it is, it
seems worth commenting both so that every reader doesn't feel compelled
to verify, and so that no new callers will naively violate that
expectation)

thanks,
-serge

> +out_freepage:
> +	free_page((unsigned long)page);
> +}
> +
>  static int nfs_follow_remote_path(struct vfsmount *root_mnt,
>  		const char *export_path, struct vfsmount *mnt_target)
>  {
> @@ -2574,6 +2595,9 @@ static int nfs_follow_remote_path(struct vfsmount *root_mnt,
>  	mnt_target->mnt_sb = s;
>  	mnt_target->mnt_root = dget(nd.path.dentry);
> 
> +	/* Correct the device pathname */
> +	nfs_fix_devname(&nd.path, mnt_target);
> +
>  	path_put(&nd.path);
>  	down_write(&s->s_umount);
>  	return 0;
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/