[PATCH] io_uring: fix missing submitter_task ownership check in bpf_io_reg()

[PATCH] io_uring: fix missing submitter_task ownership check in bpf_io_reg()

[Ali Raza]

bpf_io_reg() installs a BPF struct_ops loop_step on any io_uring ring
the caller holds a file descriptor for.  io_uring_ctx_get_file() only
validates that the fd resolves to an io_uring file; it does not verify
the caller has authority over the ring's submitter_task.

A parallel path in io_uring_register() already enforces this:

    if (ctx->submitter_task && ctx->submitter_task != current)
        return -EEXIST;  /* register.c:733 */

Without the equivalent check in bpf_io_reg(), a local user with
CAP_PERFMON can exploit IORING_SETUP_R_DISABLED -- which defers
submitter_task assignment until IORING_REGISTER_ENABLE_RINGS -- to
install a loop_step on a ring before a more-privileged process becomes
its submitter_task.  The loop_step then executes in the privileged
process's task context and can issue arbitrary io_uring operations
(IORING_OP_WRITE, IORING_OP_READ, IORING_OP_SPLICE) against that
process's open file table.  This provides a cross-privilege io_uring
execution primitive that can serve as a component in a privilege
escalation chain when combined with a vector that induces a privileged
process to adopt an attacker-controlled ring.

Affected: v7.1-rc1+ with CONFIG_IO_URING_BPF_OPS=y.
Requires: IORING_SETUP_DEFER_TASKRUN | IORING_SETUP_SINGLE_ISSUER.

Add the ownership check in io_install_bpf(), which is called under
uring_lock, matching the locking context of the register.c check.

Signed-off-by: Ali Raza <elirazamumtaz@gmail.com>
Cc: Pavel Begunkov <asml.silence@gmail.com>
---
 io_uring/bpf-ops.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/io_uring/bpf-ops.c b/io_uring/bpf-ops.c
index 937e48bef40b..cac11c929297 100644
--- a/io_uring/bpf-ops.c
+++ b/io_uring/bpf-ops.c
@@ -162,6 +162,8 @@ static int io_install_bpf(struct io_ring_ctx *ctx, struct io_uring_bpf_ops *ops)
 		return -EOPNOTSUPP;
 	if (!(ctx->flags & IORING_SETUP_DEFER_TASKRUN))
 		return -EOPNOTSUPP;
+	if (ctx->submitter_task && ctx->submitter_task != current)
+		return -EPERM;
 
 	if (ctx->bpf_ops)
 		return -EBUSY;

---
base-commit: bea8d77e45a8b77f2beca1affc9aa7ed28f39b17
change-id: 20260422-master-d96fe0e8bb3c

Best regards,
--  
Ali Raza <elirazamumtaz@gmail.com>

Re: [PATCH] io_uring: fix missing submitter_task ownership check in bpf_io_reg()

[Gabriel Krisman Bertazi]

Ali Raza <elirazamumtaz@gmail.com> writes:

> bpf_io_reg() installs a BPF struct_ops loop_step on any io_uring ring
> the caller holds a file descriptor for.  io_uring_ctx_get_file() only
> validates that the fd resolves to an io_uring file; it does not verify
> the caller has authority over the ring's submitter_task.
>
> A parallel path in io_uring_register() already enforces this:
>
>     if (ctx->submitter_task && ctx->submitter_task != current)
>         return -EEXIST;  /* register.c:733 */

How is this a protection?  I thought ctx->submitter_task is about
IORING_SETUP_SINGLE_ISSUER. there is no permission or capability over
it against other processes.

> Without the equivalent check in bpf_io_reg(), a local user with
> CAP_PERFMON can exploit IORING_SETUP_R_DISABLED -- which defers

I'd argue this is a non-issue.  If you have CAP_PERFMON, you are able to
mess with the process in many ways beyond this.  Otherwise, how a
process would be able to get the fd in the first place?

> submitter_task assignment until IORING_REGISTER_ENABLE_RINGS -- to
> install a loop_step on a ring before a more-privileged process becomes
> its submitter_task.  The loop_step then executes in the privileged
> process's task context and can issue arbitrary io_uring operations
> (IORING_OP_WRITE, IORING_OP_READ, IORING_OP_SPLICE) against that
> process's open file table.  This provides a cross-privilege io_uring
> execution primitive that can serve as a component in a privilege
> escalation chain when combined with a vector that induces a privileged
> process to adopt an attacker-controlled ring.
>
> Affected: v7.1-rc1+ with CONFIG_IO_URING_BPF_OPS=y.
> Requires: IORING_SETUP_DEFER_TASKRUN | IORING_SETUP_SINGLE_ISSUER.
>
> Add the ownership check in io_install_bpf(), which is called under
> uring_lock, matching the locking context of the register.c check.
>
> Signed-off-by: Ali Raza <elirazamumtaz@gmail.com>
> Cc: Pavel Begunkov <asml.silence@gmail.com>
> ---
>  io_uring/bpf-ops.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/io_uring/bpf-ops.c b/io_uring/bpf-ops.c
> index 937e48bef40b..cac11c929297 100644
> --- a/io_uring/bpf-ops.c
> +++ b/io_uring/bpf-ops.c
> @@ -162,6 +162,8 @@ static int io_install_bpf(struct io_ring_ctx *ctx, struct io_uring_bpf_ops *ops)
>  		return -EOPNOTSUPP;
>  	if (!(ctx->flags & IORING_SETUP_DEFER_TASKRUN))
>  		return -EOPNOTSUPP;
> +	if (ctx->submitter_task && ctx->submitter_task != current)
> +		return -EPERM;
>  
>  	if (ctx->bpf_ops)
>  		return -EBUSY;
>
> ---
> base-commit: bea8d77e45a8b77f2beca1affc9aa7ed28f39b17
> change-id: 20260422-master-d96fe0e8bb3c
>
> Best regards,
> --  
>
> Ali Raza <elirazamumtaz@gmail.com>
>

-- 
Gabriel Krisman Bertazi

Re: [PATCH] io_uring: fix missing submitter_task ownership check in bpf_io_reg()

[Jens Axboe]

On 4/22/26 3:20 PM, Gabriel Krisman Bertazi wrote:
> Ali Raza <elirazamumtaz@gmail.com> writes:
> 
>> bpf_io_reg() installs a BPF struct_ops loop_step on any io_uring ring
>> the caller holds a file descriptor for.  io_uring_ctx_get_file() only
>> validates that the fd resolves to an io_uring file; it does not verify
>> the caller has authority over the ring's submitter_task.
>>
>> A parallel path in io_uring_register() already enforces this:
>>
>>     if (ctx->submitter_task && ctx->submitter_task != current)
>>         return -EEXIST;  /* register.c:733 */
> 
> How is this a protection?  I thought ctx->submitter_task is about
> IORING_SETUP_SINGLE_ISSUER. there is no permission or capability over
> it against other processes.
> 
>> Without the equivalent check in bpf_io_reg(), a local user with
>> CAP_PERFMON can exploit IORING_SETUP_R_DISABLED -- which defers
> 
> I'd argue this is a non-issue.  If you have CAP_PERFMON, you are able to
> mess with the process in many ways beyond this.  Otherwise, how a
> process would be able to get the fd in the first place?

It is a non-issue. It relies entirely on an unrealistic scenarior. Yes
if you have a privileged task that can take over a non-privileged ring
fd, yes than you can do bad things. News at 11...

-- 
Jens Axboe

Re: [PATCH] io_uring: fix missing submitter_task ownership check in bpf_io_reg()

[Pavel Begunkov]

On 4/22/26 22:20, Gabriel Krisman Bertazi wrote:
> Ali Raza <elirazamumtaz@gmail.com> writes:
> 
>> bpf_io_reg() installs a BPF struct_ops loop_step on any io_uring ring
>> the caller holds a file descriptor for.  io_uring_ctx_get_file() only
>> validates that the fd resolves to an io_uring file; it does not verify
>> the caller has authority over the ring's submitter_task.
>>
>> A parallel path in io_uring_register() already enforces this:
>>
>>      if (ctx->submitter_task && ctx->submitter_task != current)
>>          return -EEXIST;  /* register.c:733 */
> 
> How is this a protection?  I thought ctx->submitter_task is about
> IORING_SETUP_SINGLE_ISSUER. there is no permission or capability over
> it against other processes.
> 
>> Without the equivalent check in bpf_io_reg(), a local user with
>> CAP_PERFMON can exploit IORING_SETUP_R_DISABLED -- which defers
> 
> I'd argue this is a non-issue.

Right, it involves receiving a ring from an untrusted source and
then using it. Any application doing that is extremely broken,
even without any bpf you can use that to do some pretty nasty things

   If you have CAP_PERFMON, you are able to
> mess with the process in many ways beyond this.  Otherwise, how a
> process would be able to get the fd in the first place?



-- 
Pavel Begunkov

Re: [PATCH] io_uring: fix missing submitter_task ownership check in bpf_io_reg()

[Ali Raza]

On 4/22/26 10:20 PM, Gabriel Krisman Bertazi wrote:
> How is this a protection?  I thought ctx->submitter_task is about
> IORING_SETUP_SINGLE_ISSUER. there is no permission or capability over
> it against other processes.

You are correct.  submitter_task is a SINGLE_ISSUER mechanism, not a
cross-process security boundary.  The "parallel path" framing in the
commit message was inaccurate.

The code confirms it - submitter_task is only assigned under
IORING_SETUP_SINGLE_ISSUER, either at ring creation [1]:

    if (ctx->flags & IORING_SETUP_SINGLE_ISSUER
        && !(ctx->flags & IORING_SETUP_R_DISABLED))
        ctx->submitter_task = get_task_struct(current);

or deferred to IORING_REGISTER_ENABLE_RINGS [2]:

    if (ctx->flags & IORING_SETUP_SINGLE_ISSUER) {
        ctx->submitter_task = get_task_struct(current);

The check at [3] I cited returns -EEXIST to prevent a second process from
registering on a SINGLE_ISSUER ring - it has the effect of blocking
cross-process access but that is not its purpose.

The commit message's Requires: line was also incomplete:
IORING_SETUP_R_DISABLED is a prerequisite but was omitted.  Without
R_DISABLED, submitter_task is assigned to the ring creator immediately
at [1], so the attacker who creates the ring already satisfies
submitter_task == current - no timing window exists and the attack is
impossible regardless of whether the check is present.

> I'd argue this is a non-issue.  If you have CAP_PERFMON, you are able to
> mess with the process in many ways beyond this.  Otherwise, how a
> process would be able to get the fd in the first place?

On CAP_PERFMON I'd push back slightly: it is narrow (BPF program loading,
perf monitoring) and does not grant ptrace, arbitrary file write, or
process control.  The BPF struct_ops path is specifically what
CAP_PERFMON enables here, not a general process manipulation capability.

But the fd acquisition question is the real barrier, and on that point
you, Jens, and Pavel are all correct.  As Pavel noted, any application
that accepts a ring fd from an untrusted source and calls ENABLE_RINGS on
it is already catastrophically broken - the BPF vector is just one of
many things an attacker could do in that scenario.  There is no realistic
path to get a privileged process into that state without it already being
compromised by other means.

The fix itself closes a genuine asymmetry - bpf_io_reg() is the only
registration path without this guard. I can resubmit with an elaborated 
commit message, if Pavel thinks it's worth applying.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/io_uring/io_uring.c?id=bea8d77e45a8b77f2beca1affc9aa7ed28f39b17#n3053
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/io_uring/register.c?id=bea8d77e45a8b77f2beca1affc9aa7ed28f39b17#n282
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/io_uring/register.c?id=bea8d77e45a8b77f2beca1affc9aa7ed28f39b17#n733

Ali Raza