Messages in this thread | | | Subject | Re: [QUESTION] Hung task warning while running syzkaller test | From | Valentin Schneider <> | Date | Wed, 13 Nov 2019 13:55:30 +0000 |
| |
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.
| |