linux-kernel - Re: kernel panic: MAC Initialization failed.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 28 Feb 2019 07:36:42 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     syzbot <syzbot+e1b8084e532b6ee7afab@...kaller.appspotmail.com>,
        syzkaller-bugs@...glegroups.com
Cc:     jmorris@...ei.org, linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org, serge@...lyn.com,
        takedakn@...data.co.jp
Subject: Re: kernel panic: MAC Initialization failed.

On 2019/02/28 2:02, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:    7b827ff9af88 Add linux-next specific files for 20190227
> git tree:       linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=15336f14c00000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=5fa6b8975759dcc5
> dashboard link: https://syzkaller.appspot.com/bug?extid=e1b8084e532b6ee7afab
> compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17ee708ac00000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16954084c00000
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+e1b8084e532b6ee7afab@...kaller.appspotmail.com

Thank you. The LSM stacking seems to be working as expected.
But this one should not be considered as a bug.

If something went wrong before loading access control rules,
it is pointless to continue. Thus, stopping with kernel panic.

If this path is trivially triggered enough to prevent testing, syzbot can
load access control rules from /etc/tomoyo/ directory of the filesystem
image and make tomoyo_policy_loaded = true by executing /sbin/init .

Hmm, maybe we need to think about automated testing environments where
neither built-in access control rules nor run-time access control rules
can be provided ... ?

#syz invalid