linux-kernel - Re: WARNING in kernfs

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]

Message-ID: <c5672ee5-6acb-ac99-6c2d-f0fcb479e202@I-love.SAKURA.ne.jp>
Date:   Wed, 31 Oct 2018 18:56:23 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:     gregkh@...uxfoundation.org, tj@...nel.org
Cc:     syzbot <syzbot+3dcb532381f98c86aeb1@...kaller.appspotmail.com>,
        linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: WARNING in kernfs_get

On 2018/09/10 16:31, syzbot wrote:
> HEAD commit:    9a5682765a2e Merge branch 'x86-urgent-for-linus' of git://..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1624858e400000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=8f59875069d721b6
> dashboard link: https://syzkaller.appspot.com/bug?extid=3dcb532381f98c86aeb1
> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=12657f0a400000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=117728ae400000

Here is a simplified reproducer.

----------
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
	int i;
	for (i = 0; i < 16; i++)
		if (fork() == 0)
			while (1) {
				int fd = open("/dev/vhci", O_WRONLY);
				write(fd, "\xff\x80", 2);
				close(fd);
			}
	while (1)
		pause();
	return 0;
}
----------

According to debug printk() patch,
atomic_read(&kn->active) == KN_DEACTIVATED_BIAS when we hit
WARN_ON(!atomic_read(&kn->count)) at kernfs_get().

Therefore, I guess that the caller is failing to check whether
kn is already deactivated (and hence need to recreate a new
entry by that name) before reusing existing kn.