Re: [PATCH v1] io_uring/register.c: fix NULL pointer dereference in io_register_resize_rings

[Linus Torvalds]

On Mon, 9 Mar 2026 at 06:11, Jens Axboe <axboe@xxxxxxxxx> wrote:
>
> You probably want something ala:
>
> mutex_lock(&ctx->mmap_lock);
> spin_lock(&ctx->completion_lock();
> + local_irq_disable();

How could that ever work?

Irqs will happily continue on other CPUs, so disabling interrupts is
complete nonsense as far as I can tell - whether done with
spin_lock_irq() *or* with local_irq_disable()/.

So basically, touching ctx->rings from irq context in this section is
simply not an option - or the rings pointer just needs to be updated
atomically so that it doesn't matter.

I assume this was tested in qemu on a single-core setup, so that
fundamental mistake was hidden by an irrelevant configuration.

Where is the actual oops - for some inexplicable reason that had been
edited out, and it only had the call trace leading up toit? Based on
the incomplete information and the faulting address of 0x24, I'm
*guessing* that it is

        if (ctx->flags & IORING_SETUP_TASKRUN_FLAG)
                atomic_or(IORING_SQ_TASKRUN, &ctx->rings->sq_flags);

in io_req_normal_work_add(), but that may be complete garbage.

So the actual fix may be to just make damn sure that
IORING_SETUP_TASKRUN_FLAG is *not* set when the rings are resized.

But for all I know, (a) I may be looking at entirely the wrong place
and (b) there might be millions of other places that want to access
ctx->rings, so the above may be the rantings of a crazy old man.

Get off my lawn.

               Linus