Re: [PATCH] io_uring: zero remained bytes when reading to fixed kernel buffer

[Caleb Sander Mateos <csander@purestorage.com>]

On Sat, Mar 22, 2025 at 5:09 PM Ming Lei <ming.lei@redhat.com> wrote:
>
> On Sat, Mar 22, 2025 at 11:10:23AM -0700, Caleb Sander Mateos wrote:
> > On Sat, Mar 22, 2025 at 12:56 AM Ming Lei <ming.lei@redhat.com> wrote:
> > >
> > > So far fixed kernel buffer is only used for FS read/write, in which
> > > the remained bytes need to be zeroed in case of short read, otherwise
> > > kernel data may be leaked to userspace.
> >
> > I'm not sure I have all the background to understand whether kernel
> > data can be leaked through ublk requests, but I share Pavel and
> > Keith's questions about whether this scenario is even possible. If it
> > is possible, I don't think this patch would cover all the affected
> > cases:
> > - Registered ublk buffers can be used with any io_uring operation, not
> > just read/write. Wouldn't the same issue apply when using the ublk
> > buffer with, say, a socket recv or an NVMe passthru operation?
>
> IORING_RECVSEND_FIXED_BUF isn't handled for recv yet, so looks socket recv
> isn't enabled...

True, that specific example doesn't work. But my point was just that
the issue (if it exists) wouldn't be specific to read/write
operations. In fact, the ublk server could complete the read request
without performing any I/O at all to fill in its buffer.

>
> > - Wouldn't the same issue apply if the ublk server completes a ublk
> > read request without performing any I/O (zero-copy or not) to read
> > data into its buffer?
>
> Yes, it needs ublk zc server implementation to be trusted, and ublk zc
> can't work in unprivileted mode.
>
> For non-zc, no such risk because request buffer is filled with user data.

The issue doesn't appear specific to zero-copy. If the ublk device is
configured with UBLK_F_USER_COPY, a buggy/malicious ublk server that
doesn't fill in the read request's full buffer would also leak the
existing contents of the buffers. But both UBLK_F_USER_COPY and
UBLK_F_SUPPORT_ZERO_COPY require CAP_SYS_ADMIN. So I think it's
reasonable to say that we are trusting any privileged ublk server to
fully initialize read requests' buffers.

Best,
Caleb