On 7/7/20 6:46 AM, Pavel Begunkov wrote:
> On 04/07/2020 09:49, Pavel Begunkov wrote:
>> On 04/07/2020 00:32, Jann Horn wrote:
>>> On Fri, Jul 3, 2020 at 9:50 PM Pavel Begunkov <asml.silence@xxxxxxxxx> wrote:
>>>> On 03/07/2020 05:39, Jann Horn wrote:
>>>>> On Mon, Jun 29, 2020 at 10:44 PM Pavel Begunkov <asml.silence@xxxxxxxxx> wrote:
>>>>>> After __io_free_req() put a ctx ref, it should assumed that the ctx may
>>>>>> already be gone. However, it can be accessed to put back fallback req.
>>>>>> Free req first and then put a req.
>>>>>
>>>>> Please stick "Fixes" tags on bug fixes to make it easy to see when the
>>>>> fixed bug was introduced (especially for ones that fix severe issues
>>>>> like UAFs). From a cursory glance, it kinda seems like this one
>>>>> _might_ have been introduced in 2b85edfc0c90ef, which would mean that
>>>>> it landed in 5.6? But I can't really tell for sure without investing
>>>>> more time; you probably know that better.
>>>>
>>>> It was there from the beginning,
>>>> 0ddf92e848ab7 ("io_uring: provide fallback request for OOM situations")
>>>>
>>>>>
>>>>> And if this actually does affect existing releases, please also stick
>>>>> a "Cc: stable@xxxxxxxxxxxxxxx" tag on it so that the fix can be
>>>>> shipped to users of those releases.
>>>>
>>>> As mentioned in the cover letter, it's pretty unlikely to ever happen.
>>>> No one seems to have seen it since its introduction in November 2019.
>>>> And as the patch can't be backported automatically, not sure it's worth
>>>> the effort. Am I misjudging here?
>>>
>>> Use-after-free bugs are often security bugs; in particular when, as in
>>> this case, data is written through the freed pointer. That means that
>>> even if this is extremely unlikely to occur in practice under normal
>>> circumstances, you should assume that someone may invest a significant
>>> amount of time into engineering some way to make this bug happen. If
>
> Jens, how would you prefer to handle this for 5.8? I can send a patch, but
> 1. it's fixed in for-5.9
> 2. it would be a merge conflict regardless of 1.
Given the type of bug and conditions required to trigger it, I think we
should just send it in for stable once it lands in 5.9. We need GFP_KERNEL
allocations to fail, the fallback req the last to be released, the ctx
freed (and reused) in an extremely short window.
If it was more severe or easier to trigger, then we could deal with the
pain of the conflict. But I don't think it's worth it for this one.
--
Jens Axboe
