From: Pavel Begunkov <[email protected]>
To: Jens Axboe <[email protected]>
Cc: Jann Horn <[email protected]>, io-uring <[email protected]>
Subject: Re: [PATCH 5/5] io_uring: fix use after free
Date: Tue, 7 Jul 2020 15:46:21 +0300 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
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 <[email protected]> wrote:
>>> On 03/07/2020 05:39, Jann Horn wrote:
>>>> On Mon, Jun 29, 2020 at 10:44 PM Pavel Begunkov <[email protected]> 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: [email protected]" 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.
--
Pavel Begunkov
next prev parent reply other threads:[~2020-07-07 12:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-29 10:12 [PATCH 0/5] cleanup for req_free/find_next Pavel Begunkov
2020-06-29 10:12 ` [PATCH 1/5] io_uring: deduplicate freeing linked timeouts Pavel Begunkov
2020-06-29 10:13 ` [PATCH 2/5] io_uring: replace find_next() out param with ret Pavel Begunkov
2020-06-29 10:13 ` [PATCH 3/5] io_uring: kill REQ_F_TIMEOUT Pavel Begunkov
2020-06-29 10:13 ` [PATCH 4/5] io_uring: kill REQ_F_TIMEOUT_NOSEQ Pavel Begunkov
2020-06-29 10:13 ` [PATCH 5/5] io_uring: fix use after free Pavel Begunkov
2020-07-03 2:39 ` Jann Horn
2020-07-03 19:48 ` Pavel Begunkov
2020-07-03 21:32 ` Jann Horn
2020-07-04 6:49 ` Pavel Begunkov
2020-07-07 12:46 ` Pavel Begunkov [this message]
2020-07-07 13:56 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox