Pull io_uring fixes from Jens Axboe:

 - Fix a use-after-free in the bpf-ops struct_ops path, where the same
   io_uring_bpf_ops map could be registered more than once.

 - Fix the deferred iovec free for the provided-buffer grow path, which
   could leave the caller with a dangling iovec and result in repeated
   frees. Follow-up to the earlier fix in this series.

 - Zero-check the unused addr3/pad2 SQE fields for unlinkat

* tag 'io_uring-7.2-20260717' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
  io_uring/bpf-ops: reject re-registration of an already-bound ops
  io_uring/fs: check unused sqe fields for unlinkat
  io_uring/kbuf: free the replaced iovec after a successful grow

io_install_bpf() only rejects a second registration on the ctx side
(ctx->bpf_ops) and sets the per-map back-pointer ops->priv
unconditionally. The struct_ops link path never advances a map past
BPF_STRUCT_OPS_STATE_READY, so the same io_uring_bpf_ops map can be
registered more than once, and bpf_io_reg() re-resolves the target ring
via fget(ops->ring_fd) on every call. A caller can therefore point the
same ring_fd at a different io_ring_ctx between two BPF_LINK_CREATE
calls.

The second registration passes the ctx->bpf_ops check (the new ctx has
none) and overwrites ops->priv, orphaning the first ctx. Teardown
(io_eject_bpf()/bpf_io_unreg()) only reaches a ctx through ops->priv, so
the orphaned ctx is never torn down: its ctx->loop_step keeps pointing
into the struct_ops trampoline, which is freed once the map is gone. A
later io_uring_enter() on the orphaned ring then calls the dangling
ctx->loop_step from io_run_loop() -- a use-after-free of freed
executable memory, reachable by a task with CAP_BPF + CAP_PERFMON.

Reject registration when ops->priv is already set, as hid_bpf_reg()
does for its struct_ops.

Cc: stable@vger.kernel.org
Fixes: 98f37634b12b ("io_uring/bpf-ops: implement bpf ops registration")
Signed-off-by: Woraphat Khiaodaeng <worapat.kd2@gmail.com>
Reviewed-by: Gabriel Krisman Bertazi <krisman@suse.de>
Reviewed-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://patch.msgid.link/20260717154537.129736-1-worapat.kd2@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>

Zero check unused SQE fields addr3 and pad2 for unlinkat. They're
not needed now, but could be used sometime in the future.

Signed-off-by: Yi Xie <xieyi@kylinos.cn>
Reviewed-by: Gabriel Krisman Bertazi <krisman@suse.de>
Link: https://patch.msgid.link/20260714030306.64820-1-xieyi@kylinos.cn
Signed-off-by: Jens Axboe <axboe@kernel.dk>

The provided-buffer validation fix deferred freeing a cached iovec
until validation completed. However, the deferred free uses arg->iovs.
After a grow, that points to the newly allocated array. Without a grow,
it points to the cached array that remains in use.

This leaves the caller with a dangling iovec in both cases and can
result in repeated frees. Only free org_iovs when arg->iovs actually
replaced it.

Fixes: cd053d788c3f ("io_uring: fix dangling iovec after provided-buffer bundle grow failure")
Assisted-by: Codex:gpt-5.3-codex-spark
Signed-off-by: Jaeyeong Lee <iostreampy@proton.me>
Link: https://patch.msgid.link/20260712142612.188695595-iostreampy@proton.me
Signed-off-by: Jens Axboe <axboe@kernel.dk>

Pull io_uring fixes from Jens Axboe:

 - Restore full RCU read section in io_req_local_work_add(), which was
   mistakenly dropped with the DEFER_TASKRUN rework in this merge
   window. Revert the commit that grabbed the RCU read lock in
   io_ctx_mark_taskrun(), as that's no longer required with the previous
   fix.

 - Fix a dangling iovec after a provided-buffer bundle grow failure,
   also an issue introduced in this merge window.

 - Reject IORING_CQE_F_32 flag pass-through in MSG_RING to rings that
   weren't setup with CQE32 or CQE_MIXED.

 - Return -EINVAL rather than -ENOMEM from get_unmapped_area() when mmap
   validation fails, matching io_uring_mmap().

* tag 'io_uring-7.2-20260710' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
  Revert "io_uring: grab RCU read lock marking task run"
  io_uring: restore RCU read section in io_req_local_work_add()
  io_uring: fix dangling iovec after provided-buffer bundle grow failure
  io_uring/uring_cmd: fix uring_cmd.c comments
  io_uring/msg_ring: reject CQE32 flag pass-through to normal rings
  io_uring/memmap: return -EINVAL from get_unmapped_area() on bad mmap

This reverts commit ed64f5c546b3d5e3a4840f6c055448ce90edf56c.

Since commit:

648790e09527 ("io_uring: restore RCU read section in io_req_local_work_add()")

io_ctx_mark_taskrun() is only ever called with the RCU read lock
already held, like previously. Hence's there's no need for this commit
anymore, which grabbed the RCU read lock inside io_ctx_mark_taskrun().

Signed-off-by: Jens Axboe <axboe@kernel.dk>

The task-work refactor that moved io_req_local_work_add() out of
io_uring.c into the new io_uring/tw.c dropped the whole-body
guard(rcu)() that used to cover the function body.

For DEFER_TASKRUN rings the ring teardown still relies on that RCU read
section pairing with its grace period:

	/* pairs with RCU read section in io_req_local_work_add() */
	if (ctx->flags & IORING_SETUP_DEFER_TASKRUN)
		synchronize_rcu();
	io_ring_ctx_free(ctx);

io_req_local_work_add() keeps dereferencing ctx after mpscq_push() has
published the request to the work list (ctx->cq_wait_nr, and
ctx->submitter_task in the final wake_up_state()), without holding a ctx
reference across that window. The RCU read section was the only thing
guaranteeing an in-flight adder had finished touching ctx before
io_ring_ctx_free() ran; synchronize_rcu() only waits for readers that
are actually inside an RCU read-side critical section. With the guard
gone the grace period no longer pairs with anything on the add side, so
ctx can be freed and reused while io_req_local_work_add() is still using
it.

Fixes: d46ab2c98aba ("io_uring: switch local task_work to a mpscq")
Signed-off-by: Woraphat Khiaodaeng <worapat.kd2@gmail.com>
Link: https://patch.msgid.link/20260709035100.2269-1-worapat.kd2@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>

When growing a provided-buffer bundle, the old cached iovec is freed
before the new buffers have all been validated. If validation fails, the
request still points at the freed iovec, which can be freed again during
completion cleanup.

Fix this by deferring the free of the old cached iovec until validation
has succeeded. On failure, free the newly allocated iovec and leave the
request pointing at the original one.

Fixes: 46800585ae04 ("io_uring/kbuf: validate ring provided buffer addresses with access_ok()")
Signed-off-by: Hao-Yu Yang <naup96721@gmail.com>
Link: https://patch.msgid.link/20260706183304.919275-1-naup96721@gmail.com
Suggested-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

Fix "concelable" -> "cancelable" in the comment above
io_uring_cmd_mark_cancelable(), and fix the memory ordering comment
in __io_uring_cmd_done() to reference io_do_iopoll() and
->iopoll_completed.

Signed-off-by: Yang Xiuwei <yangxiuwei@kylinos.cn>
Link: https://patch.msgid.link/20260702082937.3707134-3-yangxiuwei@kylinos.cn
Signed-off-by: Jens Axboe <axboe@kernel.dk>

IORING_OP_MSG_RING with IORING_MSG_RING_FLAGS_PASS allows a sender to
pass completion flags through sqe->file_index. If the sender sets
IORING_CQE_F_32 in file_index, the target-side completion path treats it
as a 32b CQE and writes big_cqe[0] and big_cqe[1] into the CQ ring
regardless of whether the target ring was created with
IORING_SETUP_CQE32 or IORING_SETUP_CQE_MIXED.

On a normal 16b CQE ring, this writes 16 extra bytes (two u64 big_cqe
fields) into the next CQE slot in the ring buffer. As the receiving ring
doesn't understand 32b CQEs, this is incorrect and they should be
rejected.

Fixes: cbeb47a7b5f0 ("io_uring/msg_ring: Pass custom flags to the cqe")
Signed-off-by: Melbin K Mathew <mlbnkm1@gmail.com>
Link: https://patch.msgid.link/20260701081145.196730-1-mlbnkm1@gmail.com
[axboe: edit commit message]
Signed-off-by: Jens Axboe <axboe@kernel.dk>