[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <561B9C79.8030003@suse.cz>
Date: Mon, 12 Oct 2015 13:41:45 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Dmitry Vyukov <dvyukov@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>, dave@...olabs.net,
dave.hansen@...ux.intel.com, Hugh Dickins <hughd@...gle.com>,
Joe Perches <joe@...ches.com>, sds@...ho.nsa.gov,
Oleg Nesterov <oleg@...hat.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Rik van Riel <riel@...hat.com>, mhocko@...e.cz,
gang.chen.5i5j@...il.com, Peter Feiner <pfeiner@...gle.com>,
aarcange@...hat.com, "linux-mm@...ck.org" <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>
Cc: syzkaller@...glegroups.com, Kostya Serebryany <kcc@...gle.com>,
Alexander Potapenko <glider@...gle.com>,
Andrey Konovalov <andreyknvl@...gle.com>,
Sasha Levin <sasha.levin@...cle.com>
Subject: Re: GPF in shm_lock ipc
On 10/12/2015 11:55 AM, Dmitry Vyukov wrote:
> Hello,
>
> The following program crashes kernel:
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include <syscall.h>
> #include <string.h>
> #include <stdint.h>
>
> int main()
> {
> long r0 = syscall(SYS_shmget, 0x0ul, 0x2ul, 0x8ul);
> long r1 = syscall(SYS_shmat, r0, 0x20000000ul, 0x0ul);
> long r2 = syscall(SYS_mremap, 0x20000000ul, 0x1000ul,
> 0x3000ul, 0x3ul, 0x207f9000ul);
> long r19 = syscall(SYS_shmctl, r0, 0x0ul, 0);
> long r20 = syscall(SYS_remap_file_pages, 0x207f9000ul,
> 0x3000ul, 0x0ul, 0x7ul, 0x0ul);
> return 0;
> }
>
> On commit dd36d7393d6310b0c1adefb22fba79c3cf8a577c
> (git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git)
>
> ------------[ cut here ]------------
> WARNING: CPU: 2 PID: 2636 at ipc/shm.c:162 shm_open+0x74/0x80()
> Modules linked in:
> CPU: 2 PID: 2636 Comm: a.out Not tainted 4.3.0-rc3+ #37
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> ffffffff81bcb43c ffff88081bf0bd70 ffffffff812fe8d6 0000000000000000
> ffff88081bf0bda8 ffffffff81051ff1 ffffffffffffffea ffff88081b896ca8
> ffff880819b81620 ffff8800bbaa6d00 ffff880819b81600 ffff88081bf0bdb8
> Call Trace:
> [< inline >] __dump_stack lib/dump_stack.c:15
> [<ffffffff812fe8d6>] dump_stack+0x44/0x5e lib/dump_stack.c:50
> [<ffffffff81051ff1>] warn_slowpath_common+0x81/0xc0 kernel/panic.c:447
> [<ffffffff810520e5>] warn_slowpath_null+0x15/0x20 kernel/panic.c:480
> [< inline >] shm_lock ipc/shm.c:162
> [<ffffffff81295c64>] shm_open+0x74/0x80 ipc/shm.c:196
> [<ffffffff81295cbe>] shm_mmap+0x4e/0x80 ipc/shm.c:399 (discriminator 2)
> [<ffffffff81142d14>] mmap_region+0x3c4/0x5e0 mm/mmap.c:1627
> [<ffffffff81143227>] do_mmap+0x2f7/0x3d0 mm/mmap.c:1402
> [< inline >] do_mmap_pgoff include/linux/mm.h:1930
> [< inline >] SYSC_remap_file_pages mm/mmap.c:2694
Hmm what kind of stack unwinder catches inlines? Some external patch,
based on debuginfo?
--
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/
Powered by blists - more mailing lists