linux-kernel - fix for boot-time mnt_want

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]

Message-Id: <1205440916.4971.58.camel@nimitz.home.sr71.net>
Date:	Thu, 13 Mar 2008 13:41:55 -0700
From:	Dave Hansen <haveblue@...ibm.com>
To:	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Al Viro <viro@...celfarce.linux.theplanet.co.uk>
Cc:	Matthew Wilcox <matthew@....cx>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Christoph Hellwig <hch@....de>,
	Greg KH <greg@...ah.com>, Kay Sievers <kay.sievers@...y.org>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Miklos Szeredi <miklos@...redi.hu>
Subject: fix for boot-time mnt_want_write() bug

Al, Andrew, please pull this patch into your trees.

First of all, this is a hard bug to trigger.  I think it requires page
alloc (or slab) debugging.  It also requires that a vfsmnt has been
freed and its memory not been mapped as something else.  It must also
have had a recent mnt_writer at the time of its __mntput().  The area
where the vfsmnt was must fault when accessed.

The problem occurs when we unmount and __mntput() a vfsmount.  We go
find any cpu_writers for that mount and clear the cpu_writer->count to
zero.  That is supposed to mean that no one will ever go try and
coalesce the cpu_writer->count int to the mnt->__mnt_writers.  Buuuuuut,
that isn't quite what happens.  We only check in __clear_mnt_count() for
a NULL mount:

void __clear_mnt_count(mnt, cpu_writer)
{
 	if (!cpu_writer->mnt)
 		return;
 	atomic_add(cpu_writer->count, &cpu_writer->mnt->__mnt_writers);
 	cpu_writer->count = 0;
}

and we go ahead and dereference the mnt (which may be invalid here).  If
it *WAS* invalid, the cpu_writer->count is always 0, and we don't
actually do anything in practice to the invalid memory location except
access it.  Adding a 0 doesn't _hurt_ anything, even if there is
something else in the memory.  That's why we didn't notice this before.
Miklos, you were very right to get nervous about this area in your
review.

Either one of the hunks in the patch would have fixed Tetsuo's oops.
But, let's include both for completeness.  They're both operating on hot
cachelines at the time so it shouldn't really impact anything.

---

 linux-2.6.git-dave/fs/namespace.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

diff -puN fs/namespace.c~robind-oops-fix-bootup-1 fs/namespace.c
--- linux-2.6.git/fs/namespace.c~robind-oops-fix-bootup-1	2008-03-13 13:26:08.000000000 -0700
+++ linux-2.6.git-dave/fs/namespace.c	2008-03-13 13:26:08.000000000 -0700
@@ -186,6 +186,12 @@ static inline void __clear_mnt_count(str
 {
 	if (!cpu_writer->mnt)
 		return;
+	/*
+	 * This is in case anyone ever leaves an invalid,
+	 * old ->mnt and a count of 0.
+	 */
+	if (!cpu_writer->count)
+		return;
 	atomic_add(cpu_writer->count, &cpu_writer->mnt->__mnt_writers);
 	cpu_writer->count = 0;
 }
@@ -577,6 +583,12 @@ static inline void __mntput(struct vfsmo
 		spin_lock(&cpu_writer->lock);
 		atomic_add(cpu_writer->count, &mnt->__mnt_writers);
 		cpu_writer->count = 0;
+		/*
+		 * Might as well do this so that no one
+		 * ever sees the pointer and expects
+		 * it to be valid.
+		 */
+		cpu_writer->mnt = NULL;
 		spin_unlock(&cpu_writer->lock);
 	}
 	/*
_

-- Dave

--
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/