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]

Message-ID: <m1y2ewxbeb.fsf@fess.ebiederm.org>
Date:   Tue, 09 Mar 2021 15:30:52 -0600
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Palash Oswal <oswalpalash@...il.com>, akpm@...ux-foundation.org,
        dave@...olabs.net, Kees Cook <keescook@...omium.org>,
        linux-kernel@...r.kernel.org, mingo@...nel.org,
        peterz@...radead.org, rppt@...ux.vnet.ibm.com, sds@...ho.nsa.gov,
        syzkaller-bugs@...glegroups.com
Subject: Re: kernel panic: Attempted to kill init!

Al Viro <viro@...iv.linux.org.uk> writes:

> On Tue, Mar 09, 2021 at 11:29:14AM +0530, Palash Oswal wrote:
>
>> I observe the following result(notice the segfault in systemd):
>> root@...dbox:~# ./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.)?

There is the creation of at least one file.  I wonder if inotify or
another notification mechanism is being triggered in systemd, and
systemd handling the notification badly and falling over.

Eric