From: <gregkh@linuxfoundation.org>
To: mszeredi@redhat.com, gregkh@linuxfoundation.org
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "vfs: rename: check backing inode being equal" has been added to the 4.5-stable tree
Date: Sun, 15 May 2016 02:00:14 +0200 [thread overview]
Message-ID: <146327041454234@kroah.com> (raw)
This is a note to let you know that I've just added the patch titled
vfs: rename: check backing inode being equal
to the 4.5-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
vfs-rename-check-backing-inode-being-equal.patch
and it can be found in the queue-4.5 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 9409e22acdfc9153f88d9b1ed2bd2a5b34d2d3ca Mon Sep 17 00:00:00 2001
From: Miklos Szeredi <mszeredi@redhat.com>
Date: Wed, 11 May 2016 01:16:37 +0200
Subject: vfs: rename: check backing inode being equal
From: Miklos Szeredi <mszeredi@redhat.com>
commit 9409e22acdfc9153f88d9b1ed2bd2a5b34d2d3ca upstream.
If a file is renamed to a hardlink of itself POSIX specifies that rename(2)
should do nothing and return success.
This condition is checked in vfs_rename(). However it won't detect hard
links on overlayfs where these are given separate inodes on the overlayfs
layer.
Overlayfs itself detects this condition and returns success without doing
anything, but then vfs_rename() will proceed as if this was a successful
rename (detach_mounts(), d_move()).
The correct thing to do is to detect this condition before even calling
into overlayfs. This patch does this by calling vfs_select_inode() to get
the underlying inodes.
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/namei.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -4258,7 +4258,11 @@ int vfs_rename(struct inode *old_dir, st
bool new_is_dir = false;
unsigned max_links = new_dir->i_sb->s_max_links;
- if (source == target)
+ /*
+ * Check source == target.
+ * On overlayfs need to look at underlying inodes.
+ */
+ if (vfs_select_inode(old_dentry, 0) == vfs_select_inode(new_dentry, 0))
return 0;
error = may_delete(old_dir, old_dentry, is_dir);
Patches currently in stable-queue which might be from mszeredi@redhat.com are
queue-4.5/vfs-rename-check-backing-inode-being-equal.patch
queue-4.5/vfs-add-vfs_select_inode-helper.patch
queue-4.5/atomic_open-fix-the-handling-of-create_error.patch
reply other threads:[~2016-05-15 0:25 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=146327041454234@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=mszeredi@redhat.com \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox