linux-kernel - Re: [QUESTION] Hung task warning while running syzkaller test

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] [day] [month] [year] [list]

Date:   Wed, 13 Nov 2019 13:55:30 +0000
From:   Valentin Schneider <valentin.schneider@....com>
To:     Zhihao Cheng <chengzhihao1@...wei.com>,
        LKML <linux-kernel@...r.kernel.org>, peterz@...radead.org,
        Ingo Molnar <mingo@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        patrick.bellasi@....com, tglx@...utronix.de
Cc:     Kefeng Wang <wangkefeng.wang@...wei.com>,
        "zhangyi (F)" <yi.zhang@...wei.com>
Subject: Re: [QUESTION] Hung task warning while running syzkaller test

On 31/10/2019 01:36, Valentin Schneider wrote:
> On 29/10/2019 03:25, Zhihao Cheng wrote:
>> I don't know much about the freezer mechanism of CGroup, but I tried it. I turned off all the CGroup related config options and reproduced the hung task on a fresh busybox-made root file system. I added rootfs in attachment. So, I guess hung task has nothing to do with CGroup(freezer).
>>
> 
> That's good to know, thanks for digging some more. I'm on the move ATM but if
> I find some time I'll try to stare some more at the C reproducer.
> 

After fumbling a bit I managed to generate the same C code from your
syzkaller reproducer with:

  $ syz-prog2c -tmpdir -sandbox none -repeat -1 -segv -threaded -collide -enable close_fds -prog repro

And now I realize the actual "juicy bits" (i.e. what I get without all of
above optional arguments) is straight up asm written to some mmap'd region
that is then executed. It does seem to start up with a syscall, but there's
tons more instructions that follow:

  4007b8:	f2 aa                	repnz stos %al,%es:(%rdi)
  4007ba:	98                   	cwtl   
  4007bb:	44 13 e8             	adc    %eax,%r13d
  4007be:	0f 05                	syscall 
  <~200 more insns>

Figuring out what is in %eax and %r13d is another indirection layer,
the execution being preceded by

  asm volatile("" ::"r"(0l), "r"(1l), "r"(2l), "r"(3l), "r"(4l), "r"(5l),
	       "r"(6l), "r"(7l), "r"(8l), "r"(9l), "r"(10l), "r"(11l), "r"(12l),
	       "r"(13l));

I have no idea which registers are supposed to be picked here (I would
assume it is implementation defined?), so through objdump it goes:

  400631:	b8 00 00 00 00       	mov    $0x0,%eax
  400636:	ba 01 00 00 00       	mov    $0x1,%edx
  40063b:	b9 02 00 00 00       	mov    $0x2,%ecx
  400640:	be 03 00 00 00       	mov    $0x3,%esi
  400645:	bf 04 00 00 00       	mov    $0x4,%edi
  40064a:	41 b8 05 00 00 00    	mov    $0x5,%r8d
  400650:	41 b9 06 00 00 00    	mov    $0x6,%r9d
  400656:	41 ba 07 00 00 00    	mov    $0x7,%r10d
  40065c:	41 bb 08 00 00 00    	mov    $0x8,%r11d
  400662:	bb 09 00 00 00       	mov    $0x9,%ebx
  400667:	41 bc 0a 00 00 00    	mov    $0xa,%r12d
  40066d:	41 bd 0b 00 00 00    	mov    $0xb,%r13d
  400673:	41 be 0c 00 00 00    	mov    $0xc,%r14d
  400679:	41 bf 0d 00 00 00    	mov    $0xd,%r15d

So that should be syscall 11 (munmap for x86_64 IIUC). And it still doesn't
tell me what the thing is actually doing.

Interestingly running that on an x86_64 box gives me a segfault. Running
the version with all of the right syz-prog2c arguments just hangs on
wait4() (I let it run overnight). I suppose I'll have to rely on execprog
to run the thing, but I have to grumble about running stuff I have no idea
what it does.