netdev - Re: [PATCH v3 1/3] io_uring/rsrc: rename and export io_lock_two

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 for Android: free password hash cracker in your pocket

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

Message-ID: <c3a45eaa-0936-41a7-92cd-3332fd621f6a@gmail.com>
Date: Mon, 27 Oct 2025 10:04:08 +0000
From: Pavel Begunkov <asml.silence@...il.com>
To: David Wei <dw@...idwei.uk>, io-uring@...r.kernel.org,
 netdev@...r.kernel.org
Cc: Jens Axboe <axboe@...nel.dk>
Subject: Re: [PATCH v3 1/3] io_uring/rsrc: rename and export
 io_lock_two_rings()

On 10/26/25 17:34, David Wei wrote:
> Rename lock_two_rings() to io_lock_two_rings() and export. This will be
> used when sharing a src ifq owned by one ring with another ring. During
> this process both rings need to be locked in a deterministic order,
> similar to the current user io_clone_buffers().

unlock();
double_lock();

It's quite a bad pattern just like any temporary unlocks in the
registration path, it gives a lot of space for exploitation.

Ideally, it'd be

lock(ctx1);
zcrx = grab_zcrx(ctx1, id); // with some refcounting inside
unlock(ctx1);

lock(ctx2);
install(ctx2, zcrx);
unlock(ctx2);

And as discussed, we need to think about turning it into a temp
file, bc of sync, and it's also hard to send an io_uring fd.
Though, that'd need moving bits around to avoid refcounting
cycles.

-- 
Pavel Begunkov