Re: [BUG] io_uring: task-scoped restriction/BPF filter bypass via blind register path and R_DISABLED rings

Re: [BUG] io_uring: task-scoped restriction/BPF filter bypass via blind register path and R_DISABLED rings

[Jens Axboe]

> === Bug 1 (strongest): blind register path skips all restriction checks ===
> 
> io_uring_register_blind() (register.c:1001) dispatches
> IORING_REGISTER_SEND_MSG_RING directly without consulting the sqe_op
> allowlist, BPF opcode filter, or register_op allowlist. The blind path
> has zero restriction checks.
> 
> A task that installs a restriction denying IORING_OP_MSG_RING can bypass
> it by calling io_uring_register(-1, IORING_REGISTER_SEND_MSG_RING, ...)
> instead of submitting an SQE. The message is delivered to the target
> ring ? the forbidden MSG_RING operation executes. No restriction
> configuration can prevent this.
> 
> Root cause: the submit path (io_uring.c:1792/1893) checks
> ctx->restrictions.sqe_op and ctx->bpf_filters, but the blind register
> path reaches io_uring_sync_msg_ring() without building an io_kiocb,
> so neither check fires. The register_op allowlist (register.c:767) is
> only checked in __io_uring_register() which requires fd != -1 ? the
> blind path bypasses it entirely.

This is nonsense, they are two different things - one is an sqe op, the
other is a register op. The filter supports both, you just only set 1.

> === Bug 2: register_op allowlist bypassed via R_DISABLED ===
> 
> The register_op allowlist check (register.c:767) gates on
> !(ctx->flags & IORING_SETUP_R_DISABLED):
> 
>   if ((ctx->int_flags & IO_RING_F_REG_RESTRICTED) &&
>       !(ctx->flags & IORING_SETUP_R_DISABLED)) {
>       if (!test_bit(opcode, ctx->restrictions.register_op))
>           return -EACCES;
>   }
> 
> For ring-scoped restrictions, R_DISABLED is a transient setup window
> that ENABLE_RINGS closes. But for task-scoped restrictions cloned at
> ring creation, the sandboxed task controls R_DISABLED and can simply
> never call ENABLE_RINGS, leaving the register_op allowlist permanently
> unenforced while still issuing register opcodes.

This seems like a minor oversight, send a patch for it. If you can LLM
your way through producing all of this stuff, at least have the courtesy
to also LLM your way to a patch.

Ignored the rest, because it's also just fluffy LLM garbage.

-- 
Jens Axboe