On 5/7/22 3:16 AM, Pavel Begunkov wrote: > On 5/6/22 19:22, Jens Axboe wrote: >> On 5/6/22 10:15 AM, Jens Axboe wrote: >>> On 5/6/22 9:57 AM, Pavel Begunkov wrote: >>>> On 5/6/22 03:16, Jens Axboe wrote: >>>>> On 5/5/22 8:11 AM, Guo Xuenan wrote: >>>>>> Hi, Pavel & Jens >>>>>> >>>>>> CVE-2022-1508[1] contains an patch[2] of io_uring. As Jones reported, >>>>>> it is not enough only apply [2] to stable-5.10. >>>>>> Io_uring is very valuable and active module of linux kernel. >>>>>> I've tried to apply these two patches[3] [4] to my local 5.10 code, I >>>>>> found my understanding of io_uring is not enough to resolve all conflicts. >>>>>> >>>>>> Since 5.10 is an important stable branch of linux, we would appreciate >>>>>> your help in solving this problem. >>>>> >>>>> Yes, this really needs to get buttoned up for 5.10. I seem to recall >>>>> there was a reproducer for this that was somewhat saner than the >>>>> syzbot one (which doesn't do anything for me). Pavel, do you have one? >>>> >>>> No, it was the only repro and was triggering the problem >>>> just fine back then >>> >>> I modified it a bit and I can now trigger it. >> >> Pavel, why don't we just keep it really simple and just always save the >> iter state in read/write, and use the restore instead of the revert? > > The problem here is where we're doing revert. If it's done deep in > the stack and then while unwinding someone decides to revert it again, > e.g. blkdev_read_iter(), we're screwed. > > The last attempt was backporting 20+ patches that would move revert > into io_read/io_write, i.e. REQ_F_REISSUE, back that failed some of > your tests back then. (was it read retry tests iirc?) Do you still have that series? Yes, if I recall correctly, the series had an issue with the resubmit. Which might just be minor, I don't believe we really took a closer look at that. Let's resurrect that series and see if we can pull it to completion, would be nice to finally close the chapter on this issue for 5.10... -- Jens Axboe
