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

[Jens Axboe]

On Mar 9, 2026, at 10:05 AM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxx> wrote:
> 
> 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.

Nah you’re totally right. I’m operating in few hours of sleep and on a plane. I’ll take a closer look later. The flag mask protecting it is a good idea, another one could be just a specific irq safe resize lock would be better here.

Jens