Hi,
Thanks.
Regards,
Yang
Pavel Begunkov <asml.silence@xxxxxxxxx> 于2023年5月23日周二 20:15写道：
>
> On 5/22/23 08:55, yang lan wrote:
> > Hi,
> >
> > Thanks. I'm also analyzing the root cause of this bug.
>
> The repro indeed triggers, this time in another place. Though
> when I patch all of them it would fail somewhere else, like in
> ext4 on a pagefault.
>
> We can add a couple more those "don't oom but fail" and some
> niceness around, but I think it's fine as it is as allocations
> are under cgroup. If admin cares about collision b/w users there
> should be cgroups, so allocations of one don't affect another. And
> if a user pushes it to the limit and oom's itself and gets OOM,
> that should be fine.
>
> > By the way, can I apply for a CVE? And should I submit a request to
> > some official organizations, such as Openwall, etc?
>
> Sorry, but we cannot help you here. We don't deal with CVEs.
>
> That aside, I'm not even sure it's CVE'able because it shouldn't
> be exploitable in a configured environment (unless it is). But
> I'm not an expert in that so might be wrong.
>
>
>
> > Pavel Begunkov <asml.silence@xxxxxxxxx> 于2023年5月22日周一 08:45写道：
> >>
> >> On 5/20/23 10:38, yang lan wrote:
> >>> Hi,
> >>>
> >>> Thanks for your response.
> >>>
> >>> But I applied this patch to LTS kernel 5.10.180, it can still trigger this bug.
> >>>
> >>> --- io_uring/io_uring.c.back 2023-05-20 17:11:25.870550438 +0800
> >>> +++ io_uring/io_uring.c 2023-05-20 16:35:24.265846283 +0800
> >>> @@ -1970,7 +1970,7 @@
> >>> static struct io_kiocb *io_alloc_req(struct io_ring_ctx *ctx)
> >>> __must_hold(&ctx->uring_lock)
> >>> {
> >>> struct io_submit_state *state = &ctx->submit_state;
> >>> - gfp_t gfp = GFP_KERNEL | __GFP_NOWARN;
> >>> + gfp_t gfp = GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY;
> >>> int ret, i;
> >>>
> >>> BUILD_BUG_ON(ARRAY_SIZE(state->reqs) < IO_REQ_ALLOC_BATCH);
> >>>
> >>> The io_uring.c.back is the original file.
> >>> Do I apply this patch wrong?
> >>
> >> The patch looks fine. I run a self-written test before
> >> sending with 6.4, worked as expected. I need to run the syz
> >> test, maybe it shifted to another spot, e.g. in provided
> >> buffers.
> >>
> >> --
> >> Pavel Begunkov
>
> --
> Pavel Begunkov
