linux-kernel - Recent VFS/LSM patches cause Kernel panic

lists.openwall.net		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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 20 Dec 2018 04:30:05 +0000
From:   Dexuan Cui <decui@...rosoft.com>
To:     David Howells <dhowells@...hat.com>,
        John Johansen <john.johansen@...onical.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        James Morris <jmorris@...ei.org>,
        James Morris <James.Morris@...rosoft.com>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Alexander Viro <viro@...iv.linux.org.uk>
CC:     "Adrian Vladu (Cloudbase Solutions SRL)" <v-advlad@...rosoft.com>,
        Michael Kelley <mikelley@...rosoft.com>,
        Sasha Levin <Alexander.Levin@...rosoft.com>,
        "apparmor@...ts.ubuntu.com" <apparmor@...ts.ubuntu.com>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Tejun Heo <tj@...nel.org>
Subject: Recent VFS/LSM patches cause Kernel panic - not syncing: Can't create
 rootfs

Hi,
We started to see a "Can't create rootfs" panic with linux-next's
next-20181218 and next-20181219. Note: next-20181217 is good.

Our test team found the first bad commit by git-bisect:
013c7af575e5 ("vfs: Implement a filesystem superblock creation/configuration context")

I had a look and I think another patch also helped to cause the panic:
c36d02347290 ("apparmor: Implement security hooks for the new mount API")

My kernel config for next-20181218, and my dmesg are attached. 
I can always reproduce the panic every time I boot up the kernel.

My finding is: the panic happens because 
start_kernel() -> vfs_caches_init() -> mnt_init() ->
sysfs_init() -> register_filesystem() -> init_mount_tree() ->
vfs_kern_mount(type, 0, "rootfs", NULL) -> vfs_get_tree() ->
security_sb_set_mnt_opts(sb, fc->security, 0, NULL) returns -EOPNOTSUPP:

int security_sb_set_mnt_opts(struct super_block *sb,
                                void *mnt_opts,
                                unsigned long kern_flags,
                                unsigned long *set_kern_flags)
{
        return call_int_hook(sb_set_mnt_opts,
                                mnt_opts ? -EOPNOTSUPP : 0, sb,
                                mnt_opts, kern_flags, set_kern_flags);
}

This means: fc->security is not NULL in
security_sb_set_mnt_opts(sb, fc->security, 0, NULL), and the 
security_hook_heads.FUNC is empty in call_int_hook().

The fc->security is assigned in this function (i.e. the line "fc->security = afc;" ):

static int apparmor_fs_context_parse_param(struct fs_context *fc,
                                           struct fs_parameter *param)
{
        struct apparmor_fs_context *afc = fc->security;
        const char *value;
        size_t space = 0, k_len = strlen(param->key), len = k_len, v_len;
        char *p, *q;

        if (!afc) {
                afc = kzalloc(sizeof(*afc), GFP_KERNEL);
                fc->security = afc;
        }

apparmor_fs_context_parse_param() is added recently in:
c36d02347290 ("apparmor: Implement security hooks for the new mount API")

Unluckily I know nothing about LSM, so I'm not sure if the bug is in the VFS or
LSM. Here let me Cc the related people. I suppose somebody would give a quick fix.

Thanks!
-- Dexuan


Download attachment "config.txt.tar.gz" of type "application/x-gzip" (34529 bytes)

View attachment "dmesg.txt" of type "text/plain" (12246 bytes)