linux-kernel - Re: mm: WARNING in __delete_from_page

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:	Mon, 25 Jan 2016 01:04:22 +0200
From:	"Kirill A. Shutemov" <kirill@...temov.name>
To:	Dmitry Vyukov <dvyukov@...gle.com>,
	Matthew Wilcox <willy@...ux.intel.com>
Cc:	Alexander Viro <viro@...iv.linux.org.uk>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Michal Hocko <mhocko@...e.com>, Jan Kara <jack@...e.com>,
	Vlastimil Babka <vbabka@...e.cz>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Matthew Wilcox <matthew.r.wilcox@...el.com>,
	Junichi Nomura <j-nomura@...jp.nec.com>,
	Greg Thelen <gthelen@...gle.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	syzkaller <syzkaller@...glegroups.com>,
	Kostya Serebryany <kcc@...gle.com>,
	Alexander Potapenko <glider@...gle.com>,
	Sasha Levin <sasha.levin@...cle.com>
Subject: Re: mm: WARNING in __delete_from_page_cache

On Sun, Jan 24, 2016 at 11:48:21AM +0100, Dmitry Vyukov wrote:
> Hello,
> 
> The following program triggers WARNING in __delete_from_page_cache:
> 
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 7676 at mm/filemap.c:217
> __delete_from_page_cache+0x9f6/0xb60()
> Modules linked in:
> CPU: 0 PID: 7676 Comm: a.out Not tainted 4.4.0+ #276
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>  00000000ffffffff ffff88006d3f7738 ffffffff82999e2d 0000000000000000
>  ffff8800620a0000 ffffffff86473d20 ffff88006d3f7778 ffffffff81352089
>  ffffffff81658d36 ffffffff86473d20 00000000000000d9 ffffea0000009d60
> Call Trace:
>  [<     inline     >] __dump_stack lib/dump_stack.c:15
>  [<ffffffff82999e2d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
>  [<ffffffff81352089>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
>  [<ffffffff813522b9>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
>  [<ffffffff81658d36>] __delete_from_page_cache+0x9f6/0xb60 mm/filemap.c:217
>  [<ffffffff81658fb2>] delete_from_page_cache+0x112/0x200 mm/filemap.c:244
>  [<ffffffff818af369>] __dax_fault+0x859/0x1800 fs/dax.c:487
>  [<ffffffff8186f4f6>] blkdev_dax_fault+0x26/0x30 fs/block_dev.c:1730
>  [<     inline     >] wp_pfn_shared mm/memory.c:2208
>  [<ffffffff816e9145>] do_wp_page+0xc85/0x14f0 mm/memory.c:2307
>  [<     inline     >] handle_pte_fault mm/memory.c:3323
>  [<     inline     >] __handle_mm_fault mm/memory.c:3417
>  [<ffffffff816ecec3>] handle_mm_fault+0x2483/0x4640 mm/memory.c:3446
>  [<ffffffff8127eff6>] __do_page_fault+0x376/0x960 arch/x86/mm/fault.c:1238
>  [<ffffffff8127f738>] trace_do_page_fault+0xe8/0x420 arch/x86/mm/fault.c:1331
>  [<ffffffff812705c4>] do_async_page_fault+0x14/0xd0 arch/x86/kernel/kvm.c:264
>  [<ffffffff86338f78>] async_page_fault+0x28/0x30 arch/x86/entry/entry_64.S:986
>  [<ffffffff86336c36>] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
> ---[ end trace dae21e0f85f1f98c ]---
> 
> 
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include <pthread.h>
> #include <stdint.h>
> #include <string.h>
> #include <sys/syscall.h>
> #include <unistd.h>
> #include <fcntl.h>
> 
> int main()
> {
>   syscall(SYS_mmap, 0x20000000ul, 0x10000ul, 0x3ul, 0x32ul, -1, 0x0ul);
>   int fd = syscall(SYS_open, "/dev/ram1", O_RDWR);
>   syscall(SYS_mmap, 0x20a31000ul, 0x3000ul, 0x3ul, 0xb011ul, fd, 0x0ul);
>   *(uint64_t*)0x20003000 = 1;
>   syscall(SYS_write, fd, 0x20003000ul, 0x78ul, 0, 0, 0);
>   syscall(SYS_getresuid, 0x20000688ul, 0x200008f2ul, 0x20a31000ul, 0, 0, 0);
>   return 0;
> }
> 
> On commit 30f05309bde49295e02e45c7e615f73aa4e0ccc2.

Reduced and human readable test case:

#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>

int main()
{
	int fd;
	char *p;

	fd = open("/dev/ram0", O_RDWR);
	p = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
	write(fd, "1", 1);
	*p = 1;
	return 0;
}

Looks like DAX doesn't expect to see something except hole-page in the radix
tree. This expectation is [probably] true for files on DAX-enabled
filesystems, but it seems broken for ramdisks.

Matthew?

-- 
 Kirill A. Shutemov