On Tue, Mar 9, 2021 at 3:31 PM Al Viro <v...@zeniv.linux.org.uk> wrote: > > I observe the following result(notice the segfault in systemd): > > root@sandbox:~# ./repro > > [ 9.457767] got to 221 > > [ 9.457791] got to 183 > > [ 9.459144] got to 201 > > [ 9.459471] got to 208 > > [ 9.459773] got to 210 > > [ 9.462602] got to 270 > > [ 9.488551] systemd[1]: segfault at 7ffe59fd7fb8 ip > > 000055be8f20b466 sp 00007ffe59fd7fc0 error 6 in > > systemd[55be8f15f000+ed000] > > [ 9.490723] Code: 00 00 00 00 41 57 41 56 41 55 41 54 55 53 89 fd > > 48 81 ec 48 01 00 00 64 48 8b 04 25 28 00 00 00 48 89 84 24 38 01 00 > > 00 31 c0 <e8> f5 bf f7 ff 83 f8 01 0f 84 b7 00 00 00 48 8d 9c 240 > > [ 9.492637] Kernel panic - not syncing: Attempted to kill init! > > exitcode=0x0000000b > > Lovely. So something in that sequence of syscalls manages to trigger > segfault in unrelated process. What happens if you put it to sleep > right after open_by_handle_at() (e.g. by read(2) from fd 0, etc.)?
FWIW the code looks reasonable: All code ======== 0: 00 00 add %al,(%rax) 2: 00 00 add %al,(%rax) 4: 41 57 push %r15 6: 41 56 push %r14 8: 41 55 push %r13 a: 41 54 push %r12 c: 55 push %rbp d: 53 push %rbx e: 89 fd mov %edi,%ebp 10: 48 81 ec 48 01 00 00 sub $0x148,%rsp 17: 64 48 8b 04 25 28 00 mov %fs:0x28,%rax 1e: 00 00 20: 48 89 84 24 38 01 00 mov %rax,0x138(%rsp) 27: 00 28: 31 c0 xor %eax,%eax 2a:* e8 f5 bf f7 ff callq 0xfffffffffff7c024 <-- trapping instruction 2f: 83 f8 01 cmp $0x1,%eax 32: 0f 84 b7 00 00 00 je 0xef 38: 48 rex.W 39: 8d .byte 0x8d 3a: 9c pushfq 3b: 40 rex This is a PC-relative call to a reasonable address, right? I wonder if it always traps on this instruction or not. Maybe the executable is corrupted and has a page missing in the image or something similar. But also if we suspect a badly corrupted image, is it worth pursuing it?...
