All of lore.kernel.org
 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: 22+ 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   ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.