[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <PU1P153MB0169BF1F89AE4046C9D7307FBFBF0@PU1P153MB0169.APCP153.PROD.OUTLOOK.COM>
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)
Powered by blists - more mailing lists