Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CAGyP=7dpTbbj39uO37YrNMg9h4Nzmkszc3MoZg9n8ALir_A52g@mail.gmail.com>
 <YEZcVKbPzfMVK2aK@zeniv-ca.linux.org.uk> <CAGyP=7fHhyrTP-u0tqCy5ZHzZN0v_0dAoj6dCHnFuBbqtfnBmQ@mail.gmail.com>
 <YEeFYMcdPVNrKRJT@zeniv-ca.linux.org.uk>
In-Reply-To: <YEeFYMcdPVNrKRJT@zeniv-ca.linux.org.uk>
From:   Dmitry Vyukov <dvyukov@google.com>
Date:   Tue, 9 Mar 2021 16:06:22 +0100
Message-ID: <CACT4Y+Z==NtH2K6pxN8w90cbczffF+wYbcTgTdbBczeBk5n1aw@mail.gmail.com>
Subject: Re: kernel panic: Attempted to kill init!
To:     Al Viro <viro@zeniv.linux.org.uk>
Cc:     Palash Oswal <oswalpalash@gmail.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Davidlohr Bueso <dave@stgolabs.net>,
        Kees Cook <keescook@chromium.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Ingo Molnar <mingo@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Mike Rapoport <rppt@linux.vnet.ibm.com>,
        Stephen Smalley <sds@tycho.nsa.gov>,
        syzkaller-bugs <syzkaller-bugs@googlegroups.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Mar 9, 2021 at 3:31 PM Al Viro <viro@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?...