On 5/31/22 3:14 AM, Dmitry Vyukov wrote: > On Tue, 31 May 2022 at 11:07, Jens Axboe <axboe@xxxxxxxxx> wrote: >> >> On 5/31/22 3:05 AM, Dmitry Vyukov wrote: >>> On Tue, 31 May 2022 at 11:01, Jens Axboe <axboe@xxxxxxxxx> wrote: >>>> >>>> On 5/31/22 3:00 AM, Hao Xu wrote: >>>>> On 5/31/22 16:45, Jens Axboe wrote: >>>>>> On 5/31/22 1:55 AM, syzbot wrote: >>>>>>> Hello, >>>>>>> >>>>>>> syzbot found the following issue on: >>>>>>> >>>>>>> HEAD commit: 3b46e4e44180 Add linux-next specific files for 20220531 >>>>>>> git tree: linux-next >>>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=16e151f5f00000 >>>>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=ccb8d66fc9489ef >>>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=b6c9b65b6753d333d833 >>>>>>> compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 >>>>>>> >>>>>>> Unfortunately, I don't have any reproducer for this issue yet. >>>>>>> >>>>>>> IMPORTANT: if you fix the issue, please add the following tag to the commit: >>>>>>> Reported-by: syzbot+b6c9b65b6753d333d833@xxxxxxxxxxxxxxxxxxxxxxxxx >>>>>>> >>>>>>> ================================================================================ >>>>>>> ================================================================================ >>>>>>> UBSAN: array-index-out-of-bounds in fs/io_uring.c:8860:19 >>>>>>> index 75 is out of range for type 'io_op_def [47]' >>>>>> >>>>>> 'def' is just set here, it's not actually used after 'opcode' has been >>>>>> verified. >>>>>> >>>>> >>>>> Maybe we can move it to be below the opcode check to comfort UBSAN. >>>> >>>> Yeah that's what I did, just rebased it to get rid of it: >>>> >>>> https://git.kernel.dk/cgit/linux-block/commit/?h=io_uring-5.19&id=fcde59feb1affb6d56aecadc3868df4631480da5 >>> >>> If you are rebasing it, please add the following tag so that the bug >>> is closed later: >>> >>> Tested-by: syzbot+b6c9b65b6753d333d833@xxxxxxxxxxxxxxxxxxxxxxxxx >> >> Sorry, missed that, would be a bit confusing? > > Why confusing? It tested it, no? Usually I'd use that tag if it's a separate commit that fixes an issue, and someone (or a bot) has tested it. I think we both agree that the change will fix it, but not really tested at that point. Or maybe it is now :) > >> 5.20 branch is rebased >> on top of that too. Can we just do: >> >> #syz fix: io_uring: add io_op_defs 'def' pointer in req init and issue >> >> ? > > In most cases it will work. However, there is no way to distinguish > unfixed and fixed versions of the patch based on the title. > So if the unfixed version manages to reach all syzbot builds, it will > close the bug at that point. And then can start reporting duplicates > since the bug is still present. But practically unlikely to happen. > The tag allows to distinguish unfixed and fixed versions of the patch, > so it will work reliably w/o possible duplicates. Gotcha. Usually I don't rebase anyway, but easier in this case. -- Jens Axboe
