linux-kernel - Re: [syzbot] Monthly io-uring report

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: <CANp29Y66H4-+d4hat_HCJck=u8dTn9Hw5KNzm1aYifQArQNNEw@mail.gmail.com>
Date:   Mon, 27 Mar 2023 21:12:06 +0200
From:   Aleksandr Nogikh <nogikh@...gle.com>
To:     Jens Axboe <axboe@...nel.dk>
Cc:     syzbot <syzbot+lista29bb0eabb2ddbae6f4a@...kaller.appspotmail.com>,
        io-uring@...r.kernel.org, linux-kernel@...r.kernel.org,
        syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] Monthly io-uring report

On Mon, Mar 27, 2023 at 8:23 PM Jens Axboe <axboe@...nel.dk> wrote:
>
> On 3/27/23 5:01?AM, syzbot wrote:
> > 1873    Yes   WARNING in split_huge_page_to_list (2)
> >               https://syzkaller.appspot.com/bug?extid=07a218429c8d19b1fb25
> > 38      Yes   KASAN: use-after-free Read in nfc_llcp_find_local
> >               https://syzkaller.appspot.com/bug?extid=e7ac69e6a5d806180b40
>
> These two are not io_uring. Particularly for the latter, I think syzbot
> has a tendency to guess it's io_uring if any kind of task_work is
> involved. That means anything off fput ends up in that bucket. Can we
> get that improved please?

Sure, I'll update the rules and rerun the subsystem recognition.

Currently syzbot sets io_uring if at least one is true
a) The crash stack trace points to the io_uring sources (according to
MAINTAINERS)
b) At least one reproducer has the syz_io_uring_setup call (that's a
helper function that's part of syzkaller).

In general syzbot tries to minimize the reproducer, but unfortunately
sometimes there remain some calls, which are not necessary per se. It
definitely tried to get rid of them, but the reproducer was just not
working with those calls cut out. Maybe they were just somehow
affecting the global state and in the execution log there didn't exist
any other call candidates, which could have fulfilled the purpose just
as well.

I can update b) to "all reproducers have syz_io_uring_setup". Then
those two bugs won't match the criteria.
If it doesn't suffice and there are still too many false positives, I
can drop b) completely.

By the way, should F: fs/io-wq.c also be added to the IO_URING's
record in the MAINTAINERS file?

--
Aleksandr

>
> --
> Jens Axboe
>