linux-kernel - Re: mm: uninterruptable tasks hanged on mmap

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:	Thu, 4 Feb 2016 00:34:43 +0100 (CET)
From:	Jiri Kosina <jikos@...nel.org>
To:	Dmitry Vyukov <dvyukov@...gle.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Konstantin Khlebnikov <koct9i@...il.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Takashi Iwai <tiwai@...e.de>,
	syzkaller <syzkaller@...glegroups.com>,
	Kostya Serebryany <kcc@...gle.com>,
	Alexander Potapenko <glider@...gle.com>,
	Sasha Levin <sasha.levin@...cle.com>
Subject: Re: mm: uninterruptable tasks hanged on mmap_sem

On Tue, 2 Feb 2016, Dmitry Vyukov wrote:

> If the following program run in a parallel loop, eventually it leaves
> hanged uninterruptable tasks on mmap_sem.

I am now able to reproduce the issue and will be looking into it.

[ .. snip .. ]
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include <pthread.h>
> #include <stdint.h>
> #include <string.h>
> #include <sys/syscall.h>
> #include <unistd.h>
> 
> #ifndef SYS_mlock2
> #define SYS_mlock2 325
> #endif
> 
> long r[7];
> 
> void* thr(void* arg)
> {
>   switch ((long)arg) {
>   case 0:
>     r[0] = syscall(SYS_mmap, 0x20000000ul, 0x1000ul, 0x3ul, 0x32ul,
>                    0xfffffffffffffffful, 0x0ul);
>     break;
>   case 1:
>     memcpy((void*)0x20000000, "\x2f\x64\x65\x76\x2f\x66\x64\x23", 8);

The memcpy() can be removed and the problem still triggers reliably for 
me.

>  case 3:
>    r[4] = syscall(SYS_mmap, 0x20002000ul, 0x1000ul, 0x3ul, 0x812ul,
>                   r[2], 0x0ul);

0x812 made me wonder (it's not really meaningful flags value), but the bug 
triggers also with 0x12.

-- 
Jiri Kosina
SUSE Labs