linux-next boot error (2)

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit: 509d1f0c294a Add linux-next specific files for 20180906
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=157b857a400000
kernel config: https://syzkaller.appspot.com/x/.config?x=d1a648893bbc933
dashboard link: https://syzkaller.appspot.com/bug?extid=762a577f56cfb1574647
compiler: gcc (GCC) 8.0.1 20180413 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+762a57...@syzkaller.appspotmail.com

kernel panic: VFS: Unable to mount root fs on unknown-block(8,1) driver: sd
0801 2096128 sda1 24d8ab2f-01

1f00 128 mtdblock0
(driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(8,1)
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.19.0-rc2-next-20180906+ #60
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+0x1c9/0x2b4 lib/dump_stack.c:113
panic+0x238/0x4e7 kernel/panic.c:184
mount_block_root+0x61f/0x71f init/do_mounts.c:442
mount_root+0x2d0/0x317 init/do_mounts.c:562
prepare_namespace+0x26c/0x2ab init/do_mounts.c:621
kernel_init_freeable+0x590/0x5ae init/main.c:1163
kernel_init+0x11/0x1b3 init/main.c:1063
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415
Dumping ftrace buffer:
(ftrace buffer empty)
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 syzk...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.

[David Howells]

Do we know what type of filesystem is on the root device?

Also, is there a way to tell if AppArmor denied something?

David

[Dmitry Vyukov]

On Thu, Sep 6, 2018 at 10:41 AM, David Howells <dhow...@redhat.com> wrote:
> Do we know what type of filesystem is on the root device?

ext4
The image is built with this script (you can find mkfs.ext4 there):
https://github.com/google/syzkaller/blob/master/tools/create-gce-image.sh

> Also, is there a way to tell if AppArmor denied something?

That I don't know. I guess it would have printed something.

This configuration worked before. And we don't see any errors on other trees.
A relatively recent addition was ext4 options "-O
^resize_inode,has_journal,ext_attr,extents,huge_file,flex_bg,dir_nlink,sparse_super".
But I think we already tested with them and that all worked.

[David Howells]

Andrei Vagin spotted a missing change to apparmor:
apparmor_fs_context_parse_param() needs to return -ENOPARAM, not 0.

David

[Stephen Rothwell]

Hi David,

On Tue, 11 Sep 2018 21:16:27 +0100 David Howells <dhow...@redhat.com> wrote:
>
> Andrei Vagin spotted a missing change to apparmor:
> apparmor_fs_context_parse_param() needs to return -ENOPARAM, not 0.

I will apply this fix until the proper fix arrives in the vfs tree:

From: Stephen Rothwell <s...@canb.auug.org.au>
Date: Wed, 12 Sep 2018 06:27:43 +1000
Subject: [PATCH] apparmor: fix a return value

Signed-off-by: Stephen Rothwell <s...@canb.auug.org.au>
---
security/apparmor/lsm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index c316d4237d94..416204ea713d 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -602,7 +602,7 @@ static int apparmor_fs_context_parse_param(struct fs_context *fc,

afc->saved_options = p;
afc->saved_size += 1 + len;
- return 0;
+ return -ENOPARAM;
}

static int apparmor_sb_mountpoint(struct fs_context *fc, struct path *mountpoint,
--
2.19.0.rc2

--
Cheers,
Stephen Rothwell

[David Howells]

Stephen Rothwell <s...@canb.auug.org.au> wrote:

> I will apply this fix until the proper fix arrives in the vfs tree:

Thanks.

David

[Dmitry Vyukov]

This was fixed in September, but the Reported-by tag wasn't added and
nobody told syzbot that this is fixed. So the bug is still considered
open:
https://syzkaller.appspot.com/bug?extid=762a577f56cfb1574647
10 days ago linux-next become broken for another reason, but syzbot
did not report a new bug because the previous one is still open (new
reports are merged into the existing open bug).

Please either use the Reported-by tag (for amended linux-next fixes
Tested-by can make more sense and is recognized too), or tell syzbot
separately:

#syz fix: apparmor: Implement security hooks for the new mount API

Also helps to keep dashboard relevant:
https://syzkaller.appspot.com/#upstream-open
a pile of hundreds of stale bugs is not too useful, and losing half of
bug reports in LKML archives is not good too.

Thanks in advance

[David Howells]

Dmitry Vyukov <dvy...@google.com> wrote:

> Please either use the Reported-by tag (for amended linux-next fixes
> Tested-by can make more sense and is recognized too), or tell syzbot
> separately:

It got folded in as that's better than carrying a separate patch.

I'll ask Al how he wants to deal with this since he's carrying the patches
now.

David

[Dmitry Vyukov]

A similar case in linux-next was discussed recently:
https://groups.google.com/d/msg/syzkaller-bugs/xiSF9GdiikU/uBoyYyf3AQAJ
For such cases it can make more sense to use Tested-by tag instead of
Reported-by to not confuse people that the resulting amended patch
fixes some bug (e.g. stable will try to pick it up). Tested-by is
also recognized by syzbot.

[Eric Biggers]

Neither the broken code nor the fix is anywhere to be found in linux-next or
upstream anymore, so this bug report is stuck open despite being marked with
"Fix commit: apparmor: Implement security hooks for the new mount API ".
I'm invalidating it.

#syz invalid