linux-kernel - Re: WARNING in kernfs_create_dir

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 8 Jul 2019 07:46:32 -0700
From:   Tejun Heo <tj@...nel.org>
To:     Hillf Danton <hdanton@...a.com>
Cc:     syzbot <syzbot+38f5d5cf7ae88c46b11a@...kaller.appspotmail.com>,
        gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
        syzkaller-bugs@...glegroups.com
Subject: Re: WARNING in kernfs_create_dir_ns

Hello,

On Mon, Jul 01, 2019 at 01:52:35PM +0800, Hillf Danton wrote:
> >WARNING: CPU: 0 PID: 8613 at fs/kernfs/dir.c:493 kernfs_get  fs/kernfs/dir.c:493 [inline]
> >WARNING: CPU: 0 PID: 8613 at fs/kernfs/dir.c:493 kernfs_new_node  fs/kernfs/dir.c:700 [inline]
> >WARNING: CPU: 0 PID: 8613 at fs/kernfs/dir.c:493 kernfs_create_dir_ns+0x205/0x230 fs/kernfs/dir.c:1022
...
> --- a/fs/sysfs/dir.c
> +++ b/fs/sysfs/dir.c
> @@ -53,6 +53,10 @@ int sysfs_create_dir_ns(struct kobject *kobj, const void *ns)
> 	if (!parent)
> 		return -ENOENT;
> 
> +	/* create dir if parent is not dying */
> +	if (!atomic_inc_not_zero(&parent->count))
> +		return -ENOENT;
> +
> 	kobject_get_ownership(kobj, &uid, &gid);
> 
> 	kn = kernfs_create_dir_ns(parent, kobject_name(kobj),
> @@ -61,10 +65,12 @@ int sysfs_create_dir_ns(struct kobject *kobj, const void *ns)
> 	if (IS_ERR(kn)) {
> 		if (PTR_ERR(kn) == -EEXIST)
> 			sysfs_warn_dup(parent, kobject_name(kobj));
> +		kernfs_put(parent);
> 		return PTR_ERR(kn);
> 	}
> 
> 	kobj->sd = kn;
> +	kernfs_put(parent);

I don't think this is the correct fix.  It's being called with kobj
whose parent's sysfs node is dangling.  It gotta be fixed from the
caller side.

Thanks.

-- 
tejun