Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <fd9b34f1-5289-587a-2ba3-88f924af474c@kernel.dk>
Date:   Sat, 7 May 2022 08:18:46 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.1
Subject: Re: linux-stable-5.10-y CVE-2022-1508 of io_uring module
Content-Language: en-US
To:     Pavel Begunkov <asml.silence@gmail.com>,
        Guo Xuenan <guoxuenan@huawei.com>
Cc:     lee.jones@linaro.org, linux-kernel@vger.kernel.org,
        io-uring@vger.kernel.org, yi.zhang@huawei.com, houtao1@huawei.com
References: <dd122760-5f87-10b1-e50d-388c2631c01a@kernel.dk>
 <20220505141159.3182874-1-guoxuenan@huawei.com>
 <7d54523e-372b-759b-1ebb-e0dbc181f18d@kernel.dk>
 <31ae3426-b835-3a3f-f6d1-aecad24066e8@gmail.com>
 <6c417ba7-d677-5076-5ce3-d3e174eb8899@kernel.dk>
 <4fc454ca-8b3a-28f6-2246-3ffb998f9f11@kernel.dk>
 <9c4cff81-ff0f-4819-c41d-54f28dba2929@gmail.com>
From:   Jens Axboe <axboe@kernel.dk>
In-Reply-To: <9c4cff81-ff0f-4819-c41d-54f28dba2929@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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