From nobody Sun May 5 01:21:02 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (209.51.188.17 [209.51.188.17]) by mx.zohomail.com with SMTPS id 1553961591885821.6759946741547; Sat, 30 Mar 2019 08:59:51 -0700 (PDT) Received: from localhost ([127.0.0.1]:46492 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hAGOO-0001OW-0v for importer@patchew.org; Sat, 30 Mar 2019 11:59:36 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56179) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hAGNV-00015l-5i for qemu-devel@nongnu.org; Sat, 30 Mar 2019 11:58:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hAGNM-0000sB-TW for qemu-devel@nongnu.org; Sat, 30 Mar 2019 11:58:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40914) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hAGMx-0000Oq-CO; Sat, 30 Mar 2019 11:58:09 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8E48381DF4; Sat, 30 Mar 2019 15:57:09 +0000 (UTC) Received: from blue.redhat.com (ovpn-116-75.phx2.redhat.com [10.3.116.75]) by smtp.corp.redhat.com (Postfix) with ESMTP id 494195C1A1; Sat, 30 Mar 2019 15:57:06 +0000 (UTC) From: Eric Blake To: qemu-devel@nongnu.org Date: Sat, 30 Mar 2019 10:57:04 -0500 Message-Id: <20190330155704.24191-1-eblake@redhat.com> In-Reply-To: <20190329042750.14704-1-eblake@redhat.com> References: <20190329042750.14704-1-eblake@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Sat, 30 Mar 2019 15:57:09 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH v3.1 3.5/6] nbd/client: Reject inaccessible tail of inconsistent server X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: vsementsov@virtuozzo.com, jsnow@redhat.com, rjones@redhat.com, qemu-block@nongnu.org Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" The NBD spec suggests that a server should never advertise a size inconsistent with its minimum block alignment, as that tail is effectively inaccessible to a compliant client obeying those block constraints. Since we have a habit of rounding up rather than truncating, to avoid losing the last few bytes of user input, and we cannot access the tail when the server advertises bogus block sizing, abort the connection to alert the server to fix their bug. And rejecting such servers matches what we already did for a min_block that was not a power of 2 or which was larger than max_block. Does not impact either qemu (which always sends properly aligned sizes) or nbdkit (which does not send minimum block requirements yet); so this is mostly aimed at new NBD server implementations, and ensures that the rest of our code can assume the size is aligned. Signed-off-by: Eric Blake Message-Id: <20190329163407.26919-1-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy --- This is the rewrite of the original 7/6 that I posted, retitled and hoisted earlier in the series (since Vladimir was right that 4/6 depends on it). I've added patches 1-3 to my NBD queue for a pull request on Monday as they now have R-b; I'd love to also have enough reviews for 3.5, 4, 5, 6, and also another thread on fixing 'qemu-img info' output, to include those as well. nbd/client.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/nbd/client.c b/nbd/client.c index de7da48246b..9f5eb79930c 100644 --- a/nbd/client.c +++ b/nbd/client.c @@ -426,6 +426,14 @@ static int nbd_opt_info_or_go(QIOChannel *ioc, uint32_= t opt, nbd_send_opt_abort(ioc); return -1; } + if (info->min_block && + !QEMU_IS_ALIGNED(info->size, info->min_block)) { + error_setg(errp, "server size %" PRIu64 "is not multiple o= f " + "minimum block size %" PRIu32, info->size, + info->min_block); + nbd_send_opt_abort(ioc); + return -1; + } trace_nbd_receive_negotiate_size_flags(info->size, info->flags= ); break; --=20 2.20.1