linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	stable@vger.kernel.org, Oleg Nesterov <oleg@redhat.com>,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: [PATCH 3.18 04/15] fix __legitimize_mnt()/mntput() race
Date: Thu, 16 Aug 2018 20:41:41 +0200	[thread overview]
Message-ID: <20180816171633.712842503@linuxfoundation.org> (raw)
In-Reply-To: <20180816171633.546734046@linuxfoundation.org>

3.18-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Al Viro <viro@zeniv.linux.org.uk>

commit 119e1ef80ecfe0d1deb6378d4ab41f5b71519de1 upstream.

__legitimize_mnt() has two problems - one is that in case of success
the check of mount_lock is not ordered wrt preceding increment of
refcount, making it possible to have successful __legitimize_mnt()
on one CPU just before the otherwise final mntpu() on another,
with __legitimize_mnt() not seeing mntput() taking the lock and
mntput() not seeing the increment done by __legitimize_mnt().
Solved by a pair of barriers.

Another is that failure of __legitimize_mnt() on the second
read_seqretry() leaves us with reference that'll need to be
dropped by caller; however, if that races with final mntput()
we can end up with caller dropping rcu_read_lock() and doing
mntput() to release that reference - with the first mntput()
having freed the damn thing just as rcu_read_lock() had been
dropped.  Solution: in "do mntput() yourself" failure case
grab mount_lock, check if MNT_DOOMED has been set by racing
final mntput() that has missed our increment and if it has -
undo the increment and treat that as "failure, caller doesn't
need to drop anything" case.

It's not easy to hit - the final mntput() has to come right
after the first read_seqretry() in __legitimize_mnt() *and*
manage to miss the increment done by __legitimize_mnt() before
the second read_seqretry() in there.  The things that are almost
impossible to hit on bare hardware are not impossible on SMP
KVM, though...

Reported-by: Oleg Nesterov <oleg@redhat.com>
Fixes: 48a066e72d97 ("RCU'd vsfmounts")
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/namespace.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -590,12 +590,21 @@ bool legitimize_mnt(struct vfsmount *bas
 		return true;
 	mnt = real_mount(bastard);
 	mnt_add_count(mnt, 1);
+	smp_mb();			// see mntput_no_expire()
 	if (likely(!read_seqretry(&mount_lock, seq)))
 		return true;
 	if (bastard->mnt_flags & MNT_SYNC_UMOUNT) {
 		mnt_add_count(mnt, -1);
 		return false;
 	}
+	lock_mount_hash();
+	if (unlikely(bastard->mnt_flags & MNT_DOOMED)) {
+		mnt_add_count(mnt, -1);
+		unlock_mount_hash();
+		return true;
+	}
+	unlock_mount_hash();
+
 	rcu_read_unlock();
 	mntput(bastard);
 	rcu_read_lock();
@@ -1064,6 +1073,11 @@ static void mntput_no_expire(struct moun
 		return;
 	}
 	lock_mount_hash();
+	/*
+	 * make sure that if __legitimize_mnt() has not seen us grab
+	 * mount_lock, we'll see their refcount increment here.
+	 */
+	smp_mb();
 	mnt_add_count(mnt, -1);
 	if (mnt_get_count(mnt)) {
 		rcu_read_unlock();



  parent reply	other threads:[~2018-08-16 18:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-16 18:41 [PATCH 3.18 00/15] 3.18.119-stable review Greg Kroah-Hartman
2018-08-16 18:41 ` [PATCH 3.18 01/15] xen/netfront: dont cache skb_shinfo() Greg Kroah-Hartman
2018-08-16 18:41 ` [PATCH 3.18 02/15] root dentries need RCU-delayed freeing Greg Kroah-Hartman
2018-08-16 18:41 ` [PATCH 3.18 03/15] fix mntput/mntput race Greg Kroah-Hartman
2018-08-16 18:41 ` Greg Kroah-Hartman [this message]
2018-08-16 18:41 ` [PATCH 3.18 05/15] ARM: dts: imx6sx: fix irq for pcie bridge Greg Kroah-Hartman
2018-08-16 18:41 ` [PATCH 3.18 06/15] kprobes/x86: Fix %p uses in error messages Greg Kroah-Hartman
2018-08-16 18:41 ` [PATCH 3.18 07/15] ALSA: info: Check for integer overflow in snd_info_entry_write() Greg Kroah-Hartman
2018-08-16 18:41 ` [PATCH 3.18 08/15] mm: slub: fix format mismatches in slab_err() callers Greg Kroah-Hartman
2018-08-16 18:41 ` [PATCH 3.18 09/15] i2c: ismt: fix wrong device address when unmap the data buffer Greg Kroah-Hartman
2018-08-16 18:41 ` [PATCH 3.18 10/15] kbuild: verify that $DEPMOD is installed Greg Kroah-Hartman
2018-08-16 18:41 ` [PATCH 3.18 11/15] crypto: vmac - require a block cipher with 128-bit block size Greg Kroah-Hartman
2018-08-16 18:41 ` [PATCH 3.18 12/15] crypto: vmac - separate tfm and request context Greg Kroah-Hartman
2018-08-16 18:41 ` [PATCH 3.18 13/15] crypto: blkcipher - fix crash flushing dcache in error path Greg Kroah-Hartman
2018-08-16 18:41 ` [PATCH 3.18 14/15] crypto: ablkcipher " Greg Kroah-Hartman
2018-08-16 18:41 ` [PATCH 3.18 15/15] Bluetooth: hidp: buffer overflow in hidp_process_report Greg Kroah-Hartman
2018-08-16 19:44 ` [PATCH 3.18 00/15] 3.18.119-stable review Nathan Chancellor
2018-08-17 10:08   ` Greg Kroah-Hartman
2018-08-17 13:59 ` Harsh 'Shandilya
2018-08-17 17:13   ` Greg Kroah-Hartman
2018-08-17 17:16 ` Guenter Roeck

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=20180816171633.712842503@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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;
as well as URLs for NNTP newsgroup(s).