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

[Ming Lei <ming.lei@redhat.com>]

On Sun, Mar 23, 2025 at 08:55:25AM -0700, Caleb Sander Mateos wrote:
> 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.

Now actually it has been handled in ublk driver side, which requires
both zero_copy & user_copy implementation(trusted) returns correct result
for short READ, either actual read bytes or failure code has to be returned
from ublk server.

And io_uring read/recv/.. needn't to be bothered.

> >
> > > - 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.

Right, this kind of thing(include above) should be documented.


Thanks,
Ming