linux-kernel - Re: [PATCH v5 6/6] io_uring: avoid uring_lock for IORING_SETUP_SINGLE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJnrk1ZmSYk09q2CLtBLeDA+hASka-S3K4x08B_+XXzxcOZ5-Q@mail.gmail.com>
Date: Wed, 17 Dec 2025 10:41:47 +0800
From: Joanne Koong <joannelkoong@...il.com>
To: Caleb Sander Mateos <csander@...estorage.com>
Cc: Jens Axboe <axboe@...nel.dk>, io-uring@...r.kernel.org, linux-kernel@...r.kernel.org, 
	syzbot@...kaller.appspotmail.com
Subject: Re: [PATCH v5 6/6] io_uring: avoid uring_lock for IORING_SETUP_SINGLE_ISSUER

On Wed, Dec 17, 2025 at 12:03 AM Caleb Sander Mateos
<csander@...estorage.com> wrote:
>
> On Tue, Dec 16, 2025 at 12:14 AM Joanne Koong <joannelkoong@...il.com> wrote:
> >
> > On Tue, Dec 16, 2025 at 3:47 PM Joanne Koong <joannelkoong@...il.com> wrote:
> > >
> > > On Tue, Dec 16, 2025 at 2:24 PM Caleb Sander Mateos
> > > <csander@...estorage.com> wrote:
> > > >
> > > > On Mon, Dec 15, 2025 at 8:46 PM Joanne Koong <joannelkoong@...il.com> wrote:
> >
> > Hmm, thinking about this buffer cloning + IORING_SINGLE_ISSUER
> > submitter task's buffer unregistration stuff some more though...
> > doesn't this same race with the corrupted values exist if the cloning
> > logic acquires the mutex before the submitter task formally runs and
>
> What do you mean by "before the submitter task formally runs"? The
> submitter task is running all the time, it's the one that created (or
> enabled) the io_uring and will make all the io_uring_enter() and
> io_uring_register() syscalls for the io_uring.

Ok, that's the part I was missing. I was mistakenly thinking of the
submitter task as something that gets scheduled in/out for io_uring
work specifically, rather than being the persistent task that owns and
operates the ring. That clears it up, thanks.

>
> > then the submitter task starts executing immediately right after with
> > the buffer unregistration logic while the cloning logic is
> > simultaneously executing the logic inside the mutex section? In the
> > io_ring_ctx_lock_nested() logic, I'm not seeing where this checks
> > whether the lock is currently acquired by other tasks or am I missing
> > something here and this is already accounted for?
>
> In the IORING_SETUP_SINGLE_ISSUER case, which task holds the uring
> lock is determined by which io_ring_suspend_work() task work item (if
> any) is running on the submitter_task. If io_ring_suspend_work() isn't
> running, then only submitter_task can acquire the uring lock. And it
> can do so without any additional checks because no other task can
> acquire the uring lock. (We assume the task doesn't already hold the
> uring lock, otherwise this would be a deadlock.) If an
> io_ring_suspend_work() task work item is running, then the uring lock
> has been acquired by whichever task enqueued the task work. And
> io_ring_suspend_work() won't return until that task releases the uring
> lock. So mutual exclusion is guaranteed by the fact that at most one
> task work item is executing on submitter_task at a time.
>
> Best,
> Caleb
>
> >
> > Thanks,
> > Joanne