linux-kernel - Re: fs: use after free in /proc/pid/mountinfo

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:	Wed, 9 Jul 2014 13:31:38 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Heiko Carstens <heiko.carstens@...ibm.com>
Cc:	Sasha Levin <sasha.levin@...cle.com>,
	David Rientjes <rientjes@...gle.com>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Al Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>,
	Dave Jones <davej@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: fs: use after free in /proc/pid/mountinfo

On Wed, 9 Jul 2014 16:24:06 +0200 Heiko Carstens <heiko.carstens@...ibm.com> wrote:

> 058504edd026 ("fs/seq_file: fallback to vmalloc allocation") is suspected to
> cause a crash. Actually I can't reprocude the crash nor would I be able to
> tell how the commit could cause the crash.
> Anyway, I'll be offline for the next 2.5 weeks. So if Sasha could confirm
> that reverting the patch actually does fix the crash, please revert the
> commit, unless somebody else can make sense of the report of course.
> 
> I'm still wondering how Sasha could reproduce the crash.

This really sucks :(

I suppose I'll queue up a revert of 058504edd026 as a for-3.16 bandaid.

Sasha, it would be great if you could delve a bit further into this,
see if we can identify a way for others to reproduce the bug.

Did you test that little patchlet which Heiko sent?

--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -34,12 +34,7 @@ static void seq_set_overflow(struct seq_file *m)
 
 static void *seq_buf_alloc(unsigned long size)
 {
-	void *buf;
-
-	buf = kmalloc(size, GFP_KERNEL | __GFP_NOWARN);
-	if (!buf && size > PAGE_SIZE)
-		buf = vmalloc(size);
-	return buf;
+	return kmalloc(size, GFP_KERNEL);
 }
 
 /**


It would also be interesting to try the opposite: always use vmalloc().
That may make it easier to trigger the bug.
--
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/