From: Jens Axboe <[email protected]>
To: Lee Jones <[email protected]>
Cc: Pavel Begunkov <[email protected]>,
[email protected], [email protected]
Subject: Re: [REPORT] Use-after-free Read in __fdget_raw in v5.10.y
Date: Tue, 17 May 2022 06:47:17 -0600 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 5/17/22 6:36 AM, Lee Jones wrote:
> On Tue, 17 May 2022, Jens Axboe wrote:
>
>> On 5/17/22 6:24 AM, Lee Jones wrote:
>>> On Tue, 17 May 2022, Jens Axboe wrote:
>>>
>>>> On 5/17/22 5:41 AM, Lee Jones wrote:
>>>>> Good afternoon Jens, Pavel, et al.,
>>>>>
>>>>> Not sure if you are presently aware, but there appears to be a
>>>>> use-after-free issue affecting the io_uring worker driver (fs/io-wq.c)
>>>>> in Stable v5.10.y.
>>>>>
>>>>> The full sysbot report can be seen below [0].
>>>>>
>>>>> The C-reproducer has been placed below that [1].
>>>>>
>>>>> I had great success running this reproducer in an infinite loop.
>>>>>
>>>>> My colleague reverse-bisected the fixing commit to:
>>>>>
>>>>> commit fb3a1f6c745ccd896afadf6e2d6f073e871d38ba
>>>>> Author: Jens Axboe <[email protected]>
>>>>> Date: Fri Feb 26 09:47:20 2021 -0700
>>>>>
>>>>> io-wq: have manager wait for all workers to exit
>>>>>
>>>>> Instead of having to wait separately on workers and manager, just have
>>>>> the manager wait on the workers. We use an atomic_t for the reference
>>>>> here, as we need to start at 0 and allow increment from that. Since the
>>>>> number of workers is naturally capped by the allowed nr of processes,
>>>>> and that uses an int, there is no risk of overflow.
>>>>>
>>>>> Signed-off-by: Jens Axboe <[email protected]>
>>>>>
>>>>> fs/io-wq.c | 30 ++++++++++++++++++++++--------
>>>>> 1 file changed, 22 insertions(+), 8 deletions(-)
>>>>
>>>> Does this fix it:
>>>>
>>>> commit 886d0137f104a440d9dfa1d16efc1db06c9a2c02
>>>> Author: Jens Axboe <[email protected]>
>>>> Date: Fri Mar 5 12:59:30 2021 -0700
>>>>
>>>> io-wq: fix race in freeing 'wq' and worker access
>>>>
>>>> Looks like it didn't make it into 5.10-stable, but we can certainly
>>>> rectify that.
>>>
>>> Thanks for your quick response Jens.
>>>
>>> This patch doesn't apply cleanly to v5.10.y.
>>
>> This is probably why it never made it into 5.10-stable :-/
>
> Right. It doesn't apply at all unfortunately.
>
>>> I'll have a go at back-porting it. Please bear with me.
>>
>> Let me know if you into issues with that and I can help out.
>
> I think the dependency list is too big.
>
> Too much has changed that was never back-ported.
>
> Actually the list of patches pertaining to fs/io-wq.c alone isn't so
> bad, I did start to back-port them all but some of the big ones have
> fs/io_uring.c changes incorporated and that list is huge (256 patches
> from v5.10 to the fixing patch mentioned above).
The problem is that 5.12 went to the new worker setup, and this patch
landed after that even though it also applies to the pre-native workers.
Hence the dependency chain isn't really as long as it seems, probably
just a few patches backporting the change references and completions.
I'll take a look this afternoon.
--
Jens Axboe
next prev parent reply other threads:[~2022-05-17 12:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-17 11:41 [REPORT] Use-after-free Read in __fdget_raw in v5.10.y Lee Jones
2022-05-17 11:59 ` Jens Axboe
2022-05-17 12:24 ` Lee Jones
2022-05-17 12:25 ` Jens Axboe
2022-05-17 12:36 ` Lee Jones
2022-05-17 12:47 ` Jens Axboe [this message]
2022-05-17 13:00 ` Lee Jones
2022-05-17 23:52 ` Jens Axboe
2022-05-18 12:50 ` Lee Jones
2022-05-18 12:52 ` Jens Axboe
2022-05-18 12:54 ` Jens Axboe
2022-05-18 12:56 ` Jens Axboe
2022-05-18 15:14 ` Lee Jones
2022-05-18 15:20 ` Jens Axboe
2022-05-18 15:39 ` Lee Jones
2022-05-18 16:23 ` Jens Axboe
2022-05-18 16:34 ` Lee Jones
2022-05-18 17:42 ` Jens Axboe
2022-05-19 9:26 ` Lee Jones
2022-05-19 12:13 ` 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] \
[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