linux-kernel - Re: INFO: task hung in do

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

Message-ID: <20230501185955.GA604757@mit.edu>
Date:   Mon, 1 May 2023 14:59:55 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     syzbot <syzbot+18b2ab4c697021ee8369@...kaller.appspotmail.com>
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        syzkaller-bugs@...glegroups.com, viro@...iv.linux.org.uk,
        Christian Brauner <brauner@...nel.org>
Subject: Re: INFO: task hung in do_truncate (2)

On Wed, Jan 06, 2021 at 11:03:09PM -0800, syzbot wrote:
> syzbot suspects this issue was fixed by commit:
> 
> commit dfefd226b0bf7c435a58d75a0ce2f9273b9825f6
> Author: Alexey Dobriyan <adobriyan@...il.com>
> Date:   Tue Dec 15 03:15:03 2020 +0000
> 
>     mm: cleanup kstrto*() usage

This is a nonsense bisect result; I've filed a bug against syzbot[1].

[1] https://github.com/google/syzkaller/issues/3855

Looking more closely at this reproducer, it looks like it is setting
up a and configuring userfaultd on a large number of threads:

    clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x11ad690)

    res = syscall(__NR_userfaultfd, 0ul);

    syscall(__NR_ioctl, r[0], UFFDIO_API, {api=0xaa, features=0, ... });

    syscall(__NR_ioctl, -1, PPPIOCGMRU, 0ul)    returns -EBADF
        (don't know why the syzbot minimizer didn't get rid of this...)

    syscall(__NR_ioctl, r[0], UFFDIO_REGISTER,  {range={start=0x20909000, len=0x4000}, mode=UFFDIO_REGISTER_MODE_MISSING ...)

    ...

It does this in a tight loop, spawning many threads each time, and
while it doesen't always end up reporting an rcu preempt stall, and
locking up the kernel, I have manage to trigger a similar crash when
the underlying file system is btrfs, with the stack traces being
similar.  So I don't believe it is an ext4-specific bug.

#syz set subsystems: fs

I'm not an expert on userfaultd, but I'm not at all convinced what
this reproducer is doing is valid and it may be a "root an screw
itself" kind of issue.  Maybe someone who knows more about userfaultfd
can comment?

There is a C reproducer[2], but it suffers from the standard
obfuscation via ultra-non-portable-C-so-much-it-might-as- well-be-asm
problem.  The syzbot dashboard page for this can be found here[3].

[2] https://syzkaller.appspot.com/text?tag=ReproC&x=153a741e100000
[3] https://syzkaller.appspot.com/bug?id=d38f8eae55e27aaef60b4748bc77ecb712dba4b9

Thanks,

						- Ted