linux-kernel - Re: mtd: kernel BUG at arch/x86/mm/pat.c:279!

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: <1348935073.2036.147.camel@shinybook.infradead.org>
Date:	Sat, 29 Sep 2012 17:11:13 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Anatolij Gustschin <agust@...x.de>, dhowells@...hat.com
Cc:	Sasha Levin <levinsasha928@...il.com>, suresh.b.siddha@...el.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-mtd@...ts.infradead.org, linux-mm <linux-mm@...ck.org>,
	Dave Jones <davej@...hat.com>
Subject: Re: mtd: kernel BUG at arch/x86/mm/pat.c:279!

On Fri, 2012-09-28 at 20:04 +0100, David Woodhouse wrote:
> > I was really hoping it would go through the regular channels and come
> > back to me that way, since I can't really test it, and it's bigger
> > than the trivial obvious one-liners that I'm happy to commit.
> 
> I can't test it on real hardware here either, but I can pull it through
> my tree. 

Hmm... I don't have access to real hardware with mmapable flash right
now (I haven't finished setting up the machine room since moving house
last month). But you're seeing this in a case where you *don't* have
mmapable flash either. If the value of map->phys is NO_XIP (-1UL), that
should be taken to mean that you can't directly mmap it at all.

That check seems to have been missing from David's commit 402d3265 in
which he introduced the mtd_mmap() operation, and wasn't fixed in commit
dd02b67d5 where Anatolij fixed things to actually *work* in the MMU code
path. This should fix it:

diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
index f2f482b..27c2f57 100644
--- a/drivers/mtd/mtdchar.c
+++ b/drivers/mtd/mtdchar.c
@@ -1137,8 +1137,10 @@ static int mtdchar_mmap(struct file *file, struct
vm_area_struct *vma)
 	u32 len;

 	if (mtd->type == MTD_RAM || mtd->type == MTD_ROM) {
-		off = vma->vm_pgoff << PAGE_SHIFT;
 		start = map->phys;
+		if (map->phys == NO_XIP)
+			return -EINVAL;
+		off = vma->vm_pgoff << PAGE_SHIFT;
 		len = PAGE_ALIGN((start & ~PAGE_MASK) + map->size);
 		start &= PAGE_MASK;
 		if ((vma->vm_end - vma->vm_start + off) > len)

Now, we should ideally *also* handle the case where there genuinely *is*
a mappable ROM device at the very top of physical memory, and not suffer
from overflow. But that's a more esoteric case, and the patch above
seems to be the one that we want to get merged into -stable.

-- 
dwmw2

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (6171 bytes)