From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: qemu-devel@nongnu.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
Christian Schoenebeck <qemu_oss@crudebyte.com>,
anthony.perard@citrix.com, Greg Kurz <groug@kaod.org>,
Stefano Stabellini <stefano.stabellini@xilinx.com>
Subject: Re: [PATCH] 9p: init_in_iov_from_pdu can truncate the size
Date: Fri, 20 Dec 2019 13:31:29 +0100 [thread overview]
Message-ID: <60649649.mbVaKIiDdU@silver> (raw)
In-Reply-To: <alpine.DEB.2.21.1912191434260.9832@sstabellini-ThinkPad-T480s>
On Donnerstag, 19. Dezember 2019 23:36:07 CET Stefano Stabellini wrote:
> On Thu, 19 Dec 2019, Christian Schoenebeck wrote:
> > On Donnerstag, 19. Dezember 2019 01:42:51 CET Stefano Stabellini wrote:
> > > From: Stefano Stabellini <stefano.stabellini@xilinx.com>
> > >
> > > init_in_iov_from_pdu might not be able to allocate the full buffer size
> > > requested, which comes from the client and could be larger than the
> > > transport has available at the time of the request. Specifically, this
> > > can happen with read operations, with the client requesting a read up to
> > > the max allowed, which might be more than the transport has available at
> > > the time.
> >
> > I haven't looked thoroughly at this yet, but that's about addressing a
> > temporary, not a permanent transport buffer size limitation, right?
>
> Yes, that is correct.
One more thing ...
> diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
> index 775e8ff766..68873c3f5f 100644
> --- a/hw/9pfs/virtio-9p-device.c
> +++ b/hw/9pfs/virtio-9p-device.c
> @@ -145,19 +145,15 @@ static ssize_t virtio_pdu_vunmarshal(V9fsPDU *pdu,
> size_t offset, }
>
> static void virtio_init_in_iov_from_pdu(V9fsPDU *pdu, struct iovec **piov,
> - unsigned int *pniov, size_t size)
> + unsigned int *pniov, size_t *size)
> {
> V9fsState *s = pdu->s;
> V9fsVirtioState *v = container_of(s, V9fsVirtioState, state);
> VirtQueueElement *elem = v->elems[pdu->idx];
> size_t buf_size = iov_size(elem->in_sg, elem->in_num);
>
> - if (buf_size < size) {
> - VirtIODevice *vdev = VIRTIO_DEVICE(v);
> -
> - virtio_error(vdev,
> - "VirtFS reply type %d needs %zu bytes, buffer has
> %zu", - pdu->id + 1, size, buf_size);
> + if (buf_size < *size) {
> + *size = buf_size;
> }
>
> *piov = elem->in_sg;
Here could be a problem: what happens if the currently available transport
buffer size is extremely small, i.e. less than P9_IOHDRSZ? I am not sure that
would be handled safely everywhere. So maybe it would make sense to make
transport buffer size < P9_IOHDRSZ an error case here?
Best regards,
Christian Schoenebeck
next prev parent reply other threads:[~2019-12-20 12:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-19 0:42 [PATCH] 9p: init_in_iov_from_pdu can truncate the size Stefano Stabellini
2019-12-19 17:08 ` Christian Schoenebeck
2019-12-19 22:36 ` Stefano Stabellini
2019-12-20 12:31 ` Christian Schoenebeck [this message]
2020-01-06 13:42 ` Greg Kurz
2020-01-06 15:24 ` Christian Schoenebeck
2020-01-06 17:31 ` Greg Kurz
2020-01-06 19:30 ` Stefano Stabellini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60649649.mbVaKIiDdU@silver \
--to=qemu_oss@crudebyte.com \
--cc=anthony.perard@citrix.com \
--cc=groug@kaod.org \
--cc=qemu-devel@nongnu.org \
--cc=sstabellini@kernel.org \
--cc=stefano.stabellini@xilinx.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).