linux-kernel - Re: kernel panic: Attempted to kill init!

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:   Wed, 10 Mar 2021 13:03:07 +0530
From:   Palash Oswal <oswalpalash@...il.com>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     Al Viro <viro@...iv.linux.org.uk>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Davidlohr Bueso <dave@...olabs.net>,
        Kees Cook <keescook@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Mike Rapoport <rppt@...ux.vnet.ibm.com>,
        Stephen Smalley <sds@...ho.nsa.gov>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: kernel panic: Attempted to kill init!

On Tue, Mar 9, 2021 at 8:36 PM Dmitry Vyukov <dvyukov@...gle.com> wrote:
> 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?...

I copied over a new systemd binary from a fresh disk image generated
using  tools/create-image.sh in syzkaller (debootstrap) and the bug
was still reproducible.
root@...dbox:~# md5sum /lib/systemd/systemd
12b20bfd8321ef7884b4dbf974a91213  /lib/systemd/systemd
root@...dbox:~# md5sum /lib/systemd/systemd_orig
12b20bfd8321ef7884b4dbf974a91213  /lib/systemd/systemd_orig

root@...dbox:~# gcc -pthread hax.c -o repro
root@...dbox:~# ./repro
[  115.515840] got to 221
[  115.515853] got to 183
[  115.516400] got to 201
[  115.516935] got to 208
[  115.517475] got to 210
[  115.521008] got to 270
[  115.544984] systemd[1]: segfault at 7ffe972adfb8 ip
00005560fb079466 sp 00007ffe972adfc0 error 6 in
systemd[5560fafcd000+ed000]
[  115.546554] 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
[  115.548575] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
[  115.549352] CPU: 0 PID: 1 Comm: systemd Not tainted 5.11.2+ #22
[  115.549994] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.14.0-1 04/01/2014
[  115.550834] Call Trace:
[  115.551090]  dump_stack+0xb2/0xe4
[  115.551438]  panic+0x196/0x502
[  115.551798]  do_exit.cold+0x70/0x108
[  115.552170]  do_group_exit+0x78/0x120
[  115.552552]  get_signal+0x22e/0xd60
[  115.552916]  arch_do_signal_or_restart+0xef/0x890
[  115.553407]  exit_to_user_mode_prepare+0x102/0x190
[  115.553920]  irqentry_exit_to_user_mode+0x9/0x20
[  115.554412]  irqentry_exit+0x19/0x30
[  115.554781]  exc_page_fault+0xc3/0x240
[  115.555168]  ? asm_exc_page_fault+0x8/0x30
[  115.555626]  asm_exc_page_fault+0x1e/0x30
[  115.556092] RIP: 0033:0x5560fb079466
[  115.556476] 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
[  115.558399] RSP: 002b:00007ffe972adfc0 EFLAGS: 00010246
[  115.558947] RAX: 0000000000000000 RBX: 00005560fcaa7f40 RCX: 00007ff6fb1c22e3
[  115.559720] RDX: 00007ffe972ae140 RSI: 00007ffe972ae270 RDI: 0000000000000007
[  115.560475] RBP: 0000000000000007 R08: 431bde82d7b634db R09: 000000000000000b
[  115.561219] R10: 00000000ffffffff R11: 0000000000000246 R12: 00007ffe97aad190
[  115.561963] R13: 0000000000000001 R14: ffffffffffffffff R15: 0000000000000002
[  115.562768] Kernel Offset: disabled
[  115.563148] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x0000000b ]---

For sanity, I created a new disk image altogether, made a replica of
the image and ran syzkaller on the first copy of the image to find a
new reproducer for this bug.
[NEW IMAGE]                     [NEW IMAGE REPLICA]
Used by syzkaller                Used for testing the reproducer manually
After discovering the new reproducer for this fresh image, I triggered
the new reproducer on the *untainted* replica of the image and the bug
was reproducible.
This would invalidate the assumption that the image/binaries on the
image are corrupted.