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

[sashiko-bot@kernel.org]

Sashiko AI review found 2 potential issue(s):
- [Critical] Incomplete fix for privilege escalation via deferred `submitter_task` in `io_install_bpf()`
- [Medium] Denial of Service via user-triggerable WARN_ON_ONCE for missing `ops->loop_step`
--

commit 0ef4622575dbd984db4b264672ee9cc5b456a439
Author: Ali Raza <elirazamumtaz@gmail.com>

io_uring: fix missing submitter_task ownership check in bpf_io_reg()

This commit attempts to fix a cross-privilege execution vulnerability in
bpf_io_reg() where an attacker could install a malicious BPF loop_step
on a deferred ring before a privileged process adopts it.

> diff --git a/io_uring/bpf-ops.c b/io_uring/bpf-ops.c
> index 937e48bef40bc..cac11c9292971 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;

The commit message states that the vulnerability involves exploiting
IORING_SETUP_R_DISABLED, which defers submitter_task assignment. If the
ring is disabled, wouldn't ctx->submitter_task initially be NULL?

Because the check uses ctx->submitter_task && ..., the short-circuit
evaluation will evaluate to false and bypass the permission check entirely
when the submitter task is NULL. Does this allow the attacker to still
successfully install the BPF operations during the deferred assignment
window?

Should this explicitly reject registration if the submitter task is not
yet established, for example by checking:
if (!ctx->submitter_task || ctx->submitter_task != current)?

>  
>  	if (ctx->bpf_ops)
>  		return -EBUSY;

Looking a few lines further down in io_install_bpf():

	if (WARN_ON_ONCE(!ops->loop_step))
		return -EINVAL;

Since ops->loop_step comes from a user-provided BPF struct_ops map, can a
local user intentionally omit it to trigger this warning?

On systems configured with panic_on_warn=1, could this be used to trigger
a denial of service? Would it be safer to use a standard conditional
return without the warning macro?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260422-master-v1-1-e82f47558345@gmail.com?part=1