kernel panic: MAC Initialization failed.
Tetsuo Handa
penguin-kernel at i-love.sakura.ne.jp
Wed Feb 27 22:36:42 UTC 2019
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 at syzkaller.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
More information about the Linux-security-module-archive
mailing list