lkml.org 
[lkml]   [2019]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: kernel panic: MAC Initialization failed.
From
Date
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@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

\
 
 \ /
  Last update: 2019-02-27 23:37    [W:0.046 / U:0.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site