On Mon, Mar 27, 2023 at 8:23 PM Jens Axboe <axboe@xxxxxxxxx> 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 >
