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  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 <>
To:     syzbot <>,
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:
> kernel config:
> dashboard link:
> compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro:
> C reproducer:
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by:

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

Powered by blists - more mailing lists