public inbox for io-uring@vger.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Alexandre Negrel <alexandre@negrel.dev>,
	Jens Axboe <axboe@kernel.dk>, Sasha Levin <sashal@kernel.org>,
	io-uring@vger.kernel.org
Subject: [PATCH AUTOSEL 6.18] io_uring: use GFP_NOWAIT for overflow CQEs on legacy rings
Date: Wed,  7 Jan 2026 10:53:04 -0500	[thread overview]
Message-ID: <20260107155329.4063936-2-sashal@kernel.org> (raw)
In-Reply-To: <20260107155329.4063936-1-sashal@kernel.org>

From: Alexandre Negrel <alexandre@negrel.dev>

[ Upstream commit fc5ff2500976cd2710a7acecffd12d95ee4f98fc ]

Allocate the overflowing CQE with GFP_NOWAIT instead of GFP_ATOMIC. This
changes causes allocations to fail earlier in out-of-memory situations,
rather than being deferred. Using GFP_ATOMIC allows a process to exceed
memory limits.

Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220794
Signed-off-by: Alexandre Negrel <alexandre@negrel.dev>
Link: https://lore.kernel.org/io-uring/20251229201933.515797-1-alexandre@negrel.dev/
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of io_uring GFP_NOWAIT Commit

### 1. COMMIT MESSAGE ANALYSIS

The commit message is clear and well-structured:
- **Problem**: Using `GFP_ATOMIC` for overflow CQE allocations allows
  processes to exceed memory limits
- **Solution**: Change to `GFP_NOWAIT` which fails earlier in OOM
  situations
- **Bug Reference**: Links to kernel bugzilla (bug 220794) - indicates a
  real user-reported issue
- **Proper sign-offs**: Author and maintainer (Jens Axboe) signatures
  present

The key insight is that `GFP_ATOMIC` can dip into emergency memory
reserves, allowing allocations to succeed even when a process should be
constrained by memory limits. This is a resource exhaustion / memory
limit bypass issue.

### 2. CODE CHANGE ANALYSIS

The change is minimal - a single line:
```c
- ocqe = io_alloc_ocqe(ctx, cqe, big_cqe, GFP_ATOMIC);
+       ocqe = io_alloc_ocqe(ctx, cqe, big_cqe, GFP_NOWAIT);
```

**Technical mechanism of the bug:**
- `io_cqe_overflow_locked()` is called when the completion queue is full
  and entries must overflow
- This function runs with `completion_lock` held, so it cannot sleep
  (ruling out `GFP_KERNEL`)
- `GFP_ATOMIC` can access emergency memory reserves, bypassing memory
  limits
- `GFP_NOWAIT` is also non-sleeping but respects memory limits by
  failing instead of dipping into reserves

**Why the fix works:**
- Both flags are appropriate for the atomic context (holding spinlock)
- `GFP_NOWAIT` is semantically correct: the allocation should fail
  gracefully under memory pressure rather than bypass system memory
  constraints

### 3. CLASSIFICATION

- **Bug fix**: Yes - fixes memory limit bypass
- **Feature**: No - no new functionality added
- **Security-relevant**: Yes - this could be exploited for resource
  exhaustion/DoS, particularly in containerized or multi-tenant
  environments with memory cgroups

### 4. SCOPE AND RISK ASSESSMENT

- **Lines changed**: 1
- **Files touched**: 1 (io_uring/io_uring.c)
- **Complexity**: Trivial
- **Function context**: `__cold` path - not in hot path, used only
  during overflow conditions

**Risk analysis:**
- Allocation may fail more readily under memory pressure - but that's
  the *intended* behavior
- If overflow allocation fails, the CQE won't be recorded - applications
  relying on completion notifications might be affected, but this is
  correct behavior when memory is exhausted
- Very low risk of regression since this is the semantically correct
  change

### 5. USER IMPACT

- **Who is affected**: Users running io_uring workloads (databases,
  high-performance I/O applications)
- **Severity of bug**: Medium-High - allows memory limit bypass which is
  particularly problematic in:
  - Container environments (Docker, Kubernetes)
  - Systems with memory cgroups
  - Multi-tenant systems
- **Reported by users**: Yes - bugzilla link indicates real-world issue

### 6. STABILITY INDICATORS

- Accepted by Jens Axboe (io_uring maintainer)
- Has proper Link: to mailing list discussion
- Referenced bug report demonstrates real user impact
- Simple, well-understood change

### 7. DEPENDENCY CHECK

- No dependencies on other commits
- `io_alloc_ocqe()` and `io_cqe_overflow_locked()` exist in stable
  kernels
- io_uring has been present since kernel 5.1

### CONCLUSION

**Meets stable criteria:**
- ✅ Obviously correct - semantically appropriate GFP flag
- ✅ Fixes a real bug - memory limit bypass (resource exhaustion)
- ✅ Small and contained - single line change
- ✅ No new features or APIs
- ✅ Tested in mainline
- ✅ Referenced bug report shows real user impact

**Risk vs Benefit:**
- Risk: Minimal - well-understood change to allocation flags
- Benefit: Fixes a memory limit bypass that could be used for DoS

This is an ideal stable backport candidate: a tiny, surgical fix
addressing a real security-relevant bug (memory limit bypass) with
minimal risk of regression.

**YES**

 io_uring/io_uring.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
index 60adab71ad2d..93b203205a16 100644
--- a/io_uring/io_uring.c
+++ b/io_uring/io_uring.c
@@ -897,7 +897,7 @@ static __cold bool io_cqe_overflow_locked(struct io_ring_ctx *ctx,
 {
 	struct io_overflow_cqe *ocqe;
 
-	ocqe = io_alloc_ocqe(ctx, cqe, big_cqe, GFP_ATOMIC);
+	ocqe = io_alloc_ocqe(ctx, cqe, big_cqe, GFP_NOWAIT);
 	return io_cqring_add_overflow(ctx, ocqe);
 }
 
-- 
2.51.0


           reply	other threads:[~2026-01-07 15:53 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20260107155329.4063936-1-sashal@kernel.org>]

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 \
    --in-reply-to=20260107155329.4063936-2-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=alexandre@negrel.dev \
    --cc=axboe@kernel.dk \
    --cc=io-uring@vger.kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    /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