kernel panic: MAC Initialization failed.

kernel panic: MAC Initialization failed.

[syzbot]

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

  do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
  entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x441059
Code: e8 0c ad 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 bb 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffcf60be0b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000142
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000441059
RDX: 0000000000000000 RSI: 0000000020000000 RDI: 0000000000000004
RBP: 00007ffcf60be0d0 R08: 0000000000001000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffffff
R13: 0000000000000005 R14: 0000000000000000 R15: 0000000000000000
ERROR: Out of memory at tomoyo_realpath_from_path.
Kernel panic - not syncing: MAC Initialization failed.
CPU: 0 PID: 9747 Comm: syz-executor533 Not tainted 5.0.0-rc8-next-20190227  
#44
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0x172/0x1f0 lib/dump_stack.c:113
  panic+0x2cb/0x65c kernel/panic.c:214
  tomoyo_warn_oom.cold+0x35/0x43 security/tomoyo/memory.c:28
  tomoyo_realpath_from_path+0x3a8/0x730 security/tomoyo/realpath.c:320
  tomoyo_realpath_nofollow+0xc8/0xdb security/tomoyo/realpath.c:336
  tomoyo_find_next_domain+0x28c/0x1f8a security/tomoyo/domain.c:725
  tomoyo_bprm_check_security security/tomoyo/tomoyo.c:107 [inline]
  tomoyo_bprm_check_security+0x12a/0x1b0 security/tomoyo/tomoyo.c:97
  security_bprm_check+0x69/0xb0 security/security.c:751
  search_binary_handler+0x77/0x570 fs/exec.c:1644
  exec_binprm fs/exec.c:1698 [inline]
  __do_execve_file.isra.0+0x1394/0x23f0 fs/exec.c:1818
  do_execveat_common fs/exec.c:1865 [inline]
  do_execveat fs/exec.c:1893 [inline]
  __do_sys_execveat fs/exec.c:1969 [inline]
  __se_sys_execveat fs/exec.c:1961 [inline]
  __x64_sys_execveat+0xed/0x130 fs/exec.c:1961
  do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
  entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x441059
Code: e8 0c ad 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 bb 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffcf60be0b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000142
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000441059
RDX: 0000000000000000 RSI: 0000000020000000 RDI: 0000000000000004
RBP: 00007ffcf60be0d0 R08: 0000000000001000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffffff
R13: 0000000000000005 R14: 0000000000000000 R15: 0000000000000000
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with  
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

Re: kernel panic: MAC Initialization failed.

[Tetsuo Handa]

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

Re: kernel panic: MAC Initialization failed.

[Dmitry Vyukov]

On Wed, Feb 27, 2019 at 11:37 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> 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.

Hi Tetsuo,

What misconfiguration you mean?



> 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
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/8d94063c-e10c-c470-8ce0-1f86c517b1b4%40i-love.sakura.ne.jp.
> For more options, visit https://groups.google.com/d/optout.

Re: kernel panic: MAC Initialization failed.

[Tetsuo Handa]

On 2019/02/28 15:51, Dmitry Vyukov wrote:
> On Wed, Feb 27, 2019 at 11:37 PM Tetsuo Handa
>>
>> 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.
> 
> Hi Tetsuo,
> 
> What misconfiguration you mean?

To use security modules, access control rules need to be loaded. Regarding
TOMOYO, access control rules can be loaded from the kernel itself (built-in)
and/or from /etc/tomoyo/ directory via /sbin/tomoyo-init (run-time).

Since the kernel is built without built-in policy and /sbin/tomoyo-init does
not exist, memory allocation failure is handled as a fatal problem.

But if syzbot cannot test other paths due to hitting this path, we need to somehow
avoid panic(). Can you add tomoyo-tools package into your rootfs images? It is
explained at https://tomoyo.osdn.jp/2.6/chapter-3.html .

Re: kernel panic: MAC Initialization failed.

[Dmitry Vyukov]

On Thu, Feb 28, 2019 at 11:20 AM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> On 2019/02/28 15:51, Dmitry Vyukov wrote:
> > On Wed, Feb 27, 2019 at 11:37 PM Tetsuo Handa
> >>
> >> 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.
> >
> > Hi Tetsuo,
> >
> > What misconfiguration you mean?
>
> To use security modules, access control rules need to be loaded. Regarding
> TOMOYO, access control rules can be loaded from the kernel itself (built-in)
> and/or from /etc/tomoyo/ directory via /sbin/tomoyo-init (run-time).
>
> Since the kernel is built without built-in policy and /sbin/tomoyo-init does
> not exist, memory allocation failure is handled as a fatal problem.
>
> But if syzbot cannot test other paths due to hitting this path, we need to somehow
> avoid panic(). Can you add tomoyo-tools package into your rootfs images? It is
> explained at https://tomoyo.osdn.jp/2.6/chapter-3.html .


Is installing the package everything that needs to be done? It's not a
standard package, right?
What does it do? Frequently there is like 3 DVD's of some software,
but everything that needs to be done is a single system call? What
exactly from kernel perspective we need to do?

Re: kernel panic: MAC Initialization failed.

[Tetsuo Handa]

On 2019/02/28 19:23, Dmitry Vyukov wrote:
> On Thu, Feb 28, 2019 at 11:20 AM Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
>>
>> On 2019/02/28 15:51, Dmitry Vyukov wrote:
>>> On Wed, Feb 27, 2019 at 11:37 PM Tetsuo Handa
>>>>
>>>> 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.
>>>
>>> Hi Tetsuo,
>>>
>>> What misconfiguration you mean?
>>
>> To use security modules, access control rules need to be loaded. Regarding
>> TOMOYO, access control rules can be loaded from the kernel itself (built-in)
>> and/or from /etc/tomoyo/ directory via /sbin/tomoyo-init (run-time).
>>
>> Since the kernel is built without built-in policy and /sbin/tomoyo-init does
>> not exist, memory allocation failure is handled as a fatal problem.
>>
>> But if syzbot cannot test other paths due to hitting this path, we need to somehow
>> avoid panic(). Can you add tomoyo-tools package into your rootfs images? It is
>> explained at https://tomoyo.osdn.jp/2.6/chapter-3.html .
> 
> 
> Is installing the package everything that needs to be done? It's not a
> standard package, right?
> What does it do? Frequently there is like 3 DVD's of some software,
> but everything that needs to be done is a single system call? What
> exactly from kernel perspective we need to do?
> 

 From kernel perspective, just building the kernels with
CONFIG_SECURITY_TOMOYO_OMIT_USERSPACE_LOADER=y after doing

echo 'PROFILE_VERSION=20150505' > security/tomoyo/policy/profile.conf
echo '0-CONFIG={ mode=learning grant_log=no reject_log=yes }' >> security/tomoyo/policy/profile.conf

 from the kernel source tree is needed.

But the problem is that since syzbot is automated, there is no chance to
edit the content of security/tomoyo/policy/ directory when building the
kernels. Therefore, I expected that we can add tomoyo-tools package and
/etc/tomoyo/ directory generated by executing /usr/lib/tomoyo/init_policy
into the rootfs images. tomoyo-tools package is easy to install because of
little dependency (e.g. glibc and ncurses).

Maybe disabling panic() if CONFIG_FAULT_INJECTION=y is simpler...

diff --git a/security/tomoyo/memory.c b/security/tomoyo/memory.c
index 2e7fcfa..2b2d5898 100644
--- a/security/tomoyo/memory.c
+++ b/security/tomoyo/memory.c
@@ -24,7 +24,7 @@ void tomoyo_warn_oom(const char *function)
 		pr_warn("ERROR: Out of memory at %s.\n", function);
 		tomoyo_last_pid = pid;
 	}
-	if (!tomoyo_policy_loaded)
+	if (!IS_ENABLED(CONFIG_FAULT_INJECTION) && !tomoyo_policy_loaded)
 		panic("MAC Initialization failed.\n");
 }
 

Re: kernel panic: MAC Initialization failed.

[Tetsuo Handa]

On 2019/02/28 19:58, Tetsuo Handa wrote:
> But the problem is that since syzbot is automated, there is no chance to
> edit the content of security/tomoyo/policy/ directory when building the
> kernels.

Thinking again, I realized that it would be possible to automatically
generate the content of security/tomoyo/policy/ directory specialized
for fuzzing tests using some kernel config option, for syzbot can enable
some kernel config option. I'll try it.