Re: [PATCH] io_uring/kbuf: fix cross-mm interpretation of provided buffers

[Jens Axboe <axboe@kernel.dk>]

On 11/4/26 11:14 PM, Henry Martin wrote:
> Legacy provided buffers store a raw user virtual address.  It is
> recorded in io_add_buffers() and later returned verbatim by
> io_provided_buffer_select().  The consumer (recv, send, read)
> imports it as a user pointer, so it is resolved in the address
> space of whichever task issues the request.  Nothing ties a buffer
> to the address space it was provided from.
> 
> When a ring is shared between tasks with different address spaces,
> for example across fork(2) and execve(2), a consuming request reads
> from or writes to an address chosen by the provider, in the
> consumer's address space.
> 
> Record the providing task's mm in each buffer, and refuse selection
> when the consuming task runs under a different mm.  The buffer stays
> queued for its owner and the request fails with -ENOBUFS.  The mm
> reference is held while the buffer is queued.
> 
> This issue was discovered by Tencent CodeBuddy Security.

This is nonsense.

This isn't a bug. A ring is shared memory, and anyone with access to it
can write SQEs that the other side submits, with whatever addresses they
want. Provided buffers are no different from the addr field in any SQE,
and the same holds for ring provided buffers which this patch doesn't
even touch. Sharing a ring with another address space means fully
trusting it, that's inherent to the design.

-- 
Jens Axboe