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
