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]
Date:	Fri, 7 Sep 2012 11:14:00 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Sasha Levin <levinsasha928@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, dwmw2@...radead.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!

Guys, this looks like a MTD and/or io_remap_pfn_range() bug, and it's
not getting any traction.

What the f*ck is mtd_mmap() doing, and why? The problem seems to be an
overflow condition, because reserve_pfn_range() does

    reserve_memtype(paddr, paddr + size, want_flags, &flags);

and then the BUG_ON() in reserve_memtype is

    BUG_ON(start >= end);

so it very much looks like a paddr+size overflow. However, that makes
little sense too, since we're working in "u64", so I suspect the
overflow has happened somewhere earlier.

I really don't see where, though. Could somebody please take a look?
The mtdchar_mmap() types seem insane (why "u32" for len, for example?
And that whole

  off = vma->vm_pgoff << PAGE_SHIFT;

thing looks like it would overflow, since the whole point of pgoff is
that if you shift it up by PAGE_SHIFT you need to also extend to
64-bit etc.

So I would *guess* that it's the mtdchar_mmap() stuff that overflows
due to bad types, but maybe it does deeper than that?

                         Linus

On Fri, Sep 7, 2012 at 9:55 AM, Sasha Levin <levinsasha928@...il.com> wrote:
> Ping? Still seeing this with latest master...
>
> On Fri, Jun 29, 2012 at 10:48 AM, Sasha Levin <levinsasha928@...il.com> wrote:
>> Hi all,
>>
>> I've stumbled on the following while fuzzing with trinity in a KVM tools guest using latest linux-next:
>>
>> [ 3299.675163] ------------[ cut here ]------------
>> [ 3299.676027] kernel BUG at arch/x86/mm/pat.c:279!
>> [ 3299.676027] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
>> [ 3299.678596] CPU 2
>> [ 3299.678596] Pid: 21541, comm: trinity-child6 Tainted: G        W    3.5.0-rc4-next-20120628-sasha-00005-g9f23eb7 #479
>> [ 3299.678596] RIP: 0010:[<ffffffff810a8b62>]  [<ffffffff810a8b62>] reserve_memtype+0x22/0x3d0
>> [ 3299.678596] RSP: 0018:ffff88000ad61bc8  EFLAGS: 00010286
>> [ 3299.678596] RAX: 0000000000000000 RBX: fffffffffffff000 RCX: ffff88000ad61c50
>> [ 3299.678596] RDX: 0000000000000010 RSI: 0000000000000000 RDI: fffffffffffff000
>> [ 3299.696632] RBP: ffff88000ad61c08 R08: 0000000000000010 R09: ffff88002617d5a8
>> [ 3299.696632] R10: ffff88003111edc8 R11: 0000000000000001 R12: ffff88000ad61c50
>> [ 3299.696632] R13: fffffffffffff000 R14: 0000000000000000 R15: ffff88000ad61d18
>> [ 3299.696632] FS:  00007f3ffc3aa700(0000) GS:ffff880029800000(0000) knlGS:0000000000000000
>> [ 3299.696632] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [ 3299.696632] CR2: 0000000000f73ffc CR3: 000000000ad6e000 CR4: 00000000000406e0
>> [ 3299.696632] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [ 3299.696632] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> [ 3299.696632] Process trinity-child6 (pid: 21541, threadinfo ffff88000ad60000, task ffff88000a390000)
>> [ 3299.696632] Stack:
>> [ 3299.696632]  ffff88000ad61c18 ffffffff81161bc6 ffff88000ad61c18 fffffffffffff000
>> [ 3299.696632]  0000000000000010 0000000000000000 0000000000001000 ffff88000ad61d18
>> [ 3299.696632]  ffff88000ad61c88 ffffffff810a8fe2 ffff88000ad61c38 0000000000000086
>> [ 3299.696632] Call Trace:
>> [ 3299.696632]  [<ffffffff81161bc6>] ? mark_held_locks+0xf6/0x120
>> [ 3299.696632]  [<ffffffff810a8fe2>] reserve_pfn_range+0xd2/0x1e0
>> [ 3299.696632]  [<ffffffff810a912d>] track_pfn_vma_new+0x3d/0x80
>> [ 3299.696632]  [<ffffffff8120c4bc>] remap_pfn_range+0xac/0x380
>> [ 3299.696632]  [<ffffffff8220e016>] mtdchar_mmap+0xe6/0x100
>> [ 3299.696632]  [<ffffffff812145ae>] mmap_region+0x35e/0x5f0
>> [ 3299.696632]  [<ffffffff81214af9>] do_mmap_pgoff+0x2b9/0x350
>> [ 3299.696632]  [<ffffffff811ff46c>] ? vm_mmap_pgoff+0x6c/0xb0
>> [ 3299.696632]  [<ffffffff811ff484>] vm_mmap_pgoff+0x84/0xb0
>> [ 3299.696632]  [<ffffffff8124fd80>] ? fget_raw+0x260/0x260
>> [ 3299.696632]  [<ffffffff81211fde>] sys_mmap_pgoff+0x15e/0x190
>> [ 3299.696632]  [<ffffffff81985ede>] ? trace_hardirqs_on_thunk+0x3a/0x3f
>> [ 3299.696632]  [<ffffffff8106d4dd>] sys_mmap+0x1d/0x20
>> [ 3299.696632]  [<ffffffff8372a539>] system_call_fastpath+0x16/0x1b
>> [ 3299.696632] Code: 28 5b c9 c3 0f 1f 44 00 00 55 49 89 d0 48 89 e5 41 57 41 56 49 89 f6 41 55 49 89 fd 41 54 49 89 cc 53 48 83 ec 18 48 39 f7 72 0e <0f> 0b 0f 1f 40 00 eb fe 66 0f 1f 44 00 00 8b 3d 1a 5b e3 03 85
>> [ 3299.696632] RIP  [<ffffffff810a8b62>] reserve_memtype+0x22/0x3d0
>> [ 3299.696632]  RSP <ffff88000ad61bc8>
>>
--
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/