From: Maxim Levitsky <mlevitsk@redhat.com>
To: Eric Blake <eblake@redhat.com>, qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
vsementsov@virtuozzo.com,
"open list:Network Block Dev..." <qemu-block@nongnu.org>,
Max Reitz <mreitz@redhat.com>
Subject: Re: [PATCH] nbd: Don't let client send oversize strings
Date: Sun, 29 Sep 2019 21:49:50 +0300 [thread overview]
Message-ID: <5e9da6ee2de81616cb1896da390515c53967077c.camel@redhat.com> (raw)
In-Reply-To: <20190928041301.16296-1-eblake@redhat.com>
On Fri, 2019-09-27 at 23:13 -0500, Eric Blake wrote:
> Qemu as server currently won't accept export names larger than 256
> bytes, so most uses of qemu as client have no reason to get anywhere
> near the NBD spec maximum of a 4k limit per string. However, we
> didn't actually have any code that prevented the client from violating
> the protocol, which, while useful for testing corner-case server
> reactions, is probably not ideal.
>
> Signed-off-by: Eric Blake <eblake@redhat.com>
> ---
> include/block/nbd.h | 1 +
> nbd/client.c | 8 ++++++++
> 2 files changed, 9 insertions(+)
>
> diff --git a/include/block/nbd.h b/include/block/nbd.h
> index 316fd705a9e4..fcabdf0f37c3 100644
> --- a/include/block/nbd.h
> +++ b/include/block/nbd.h
> @@ -232,6 +232,7 @@ enum {
> * going larger would require an audit of more code to make sure we
> * aren't overflowing some other buffer. */
> #define NBD_MAX_NAME_SIZE 256
> +#define NBD_MAX_STRING_SIZE 4096
>
> /* Two types of reply structures */
> #define NBD_SIMPLE_REPLY_MAGIC 0x67446698
> diff --git a/nbd/client.c b/nbd/client.c
> index f6733962b49b..3f21722dd914 100644
> --- a/nbd/client.c
> +++ b/nbd/client.c
> @@ -648,6 +648,10 @@ static int nbd_send_meta_query(QIOChannel *ioc, uint32_t opt,
> if (query) {
> query_len = strlen(query);
> data_len += sizeof(query_len) + query_len;
> + if (query_len > NBD_MAX_STRING_SIZE) {
> + error_setg(errp, "x_dirty_bitmap query too long to send to server");
Is there a way not to do this here? I don't know nbd well to be honest,
and it looks like this code currently is only called for x_dirty_bitmap but
there could be more cases in the future.
nbd_negotiate_simple_meta_context which seems to be the caller of this, already mentions
a 'hack' about this :-(
Of course if you think that this is not worth the time, you can leave this as is.
> + return -1;
> + }
> } else {
> assert(opt == NBD_OPT_LIST_META_CONTEXT);
> }
> @@ -1010,6 +1014,10 @@ int nbd_receive_negotiate(AioContext *aio_context, QIOChannel *ioc,
> bool base_allocation = info->base_allocation;
>
> assert(info->name);
> + if (strlen(info->name) > NBD_MAX_STRING_SIZE) {
> + error_setg(errp, "name too long to send to server");
Maybe 'export name'?
> + return -EINVAL;
> + }
> trace_nbd_receive_negotiate_name(info->name);
>
> result = nbd_start_negotiate(aio_context, ioc, tlscreds, hostname, outioc,
Why not to do the export name check when info->name is set, that is in nbd_client_connect?
Best regards,
Maxim Levitsky
next prev parent reply other threads:[~2019-09-29 18:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-28 4:13 [PATCH] nbd: Don't let client send oversize strings Eric Blake
2019-09-29 18:49 ` Maxim Levitsky [this message]
2019-10-09 15:30 ` Eric Blake
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=5e9da6ee2de81616cb1896da390515c53967077c.camel@redhat.com \
--to=mlevitsk@redhat.com \
--cc=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.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).