From nobody Sun Oct 5 19:22:56 2025 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 ARC-Seal: i=1; a=rsa-sha256; t=1563567720; cv=none; d=zoho.com; s=zohoarc; b=B8aBQhVcblrM9KwqdFK0ZuVpuOE7t0l5rlpADym/aqPwLruwVomWVWAETR7opS5wFyD6ILX6jwnDaGFPRTX8KVijyRUw3TnSTb2l2N8RXSLcYoLdY84YRa2XsE1bEugjsfgEl6/beIxRezOLaB1iIJmknlcNOHWkX2PzG1m74EE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1563567720; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=E5cW/TpwyubEcrCsZgvjkmkI4/1EG8rCqgJr+PwDXIo=; b=SKlKkLyhnk+vZynon47EGzmSw4RkgSe6cdtJWO75zH4e0df0UwPbRYxppmIfVr+oYpaviTo0pD9+romy78cczbp7CvrBT2taY+VPQs77etBKvnKNaPDmq4nApDPclIxB2JqOiKrf0Uj6yNu1XAqK6DWnv3c1e19fK7q0fmlg4sA= ARC-Authentication-Results: i=1; mx.zoho.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 header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 156356772010235.68281511152588; Fri, 19 Jul 2019 13:22:00 -0700 (PDT) Received: from localhost ([::1]:47948 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hoZOB-0002IH-2f for importer@patchew.org; Fri, 19 Jul 2019 16:21:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33195) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hoZNs-0001It-SM for qemu-devel@nongnu.org; Fri, 19 Jul 2019 16:21:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hoZNr-0004YS-7u for qemu-devel@nongnu.org; Fri, 19 Jul 2019 16:21:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42220) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hoZNn-0004WD-Kb; Fri, 19 Jul 2019 16:21:35 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6458E308C389; Fri, 19 Jul 2019 20:21:34 +0000 (UTC) Received: from blue.redhat.com (ovpn-116-46.phx2.redhat.com [10.3.116.46]) by smtp.corp.redhat.com (Postfix) with ESMTP id 52A2619C68; Fri, 19 Jul 2019 20:21:27 +0000 (UTC) From: Eric Blake To: qemu-devel@nongnu.org Date: Fri, 19 Jul 2019 15:21:19 -0500 Message-Id: <20190719202119.24792-2-eblake@redhat.com> In-Reply-To: <20190719202119.24792-1-eblake@redhat.com> References: <20190719202119.24792-1-eblake@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.48]); Fri, 19 Jul 2019 20:21:34 +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] [PULL 1/1] nbd: Initialize reply on failure X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kevin Wolf , Thomas Huth , "open list:Network Block Dev..." , Max Reitz , Andrey Shinkevich , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" We've had two separate reports of different callers running into use of uninitialized data if s->quit is set (one detected by gcc -O3, another by valgrind), due to checking 'nbd_reply_is_simple(reply) || s->quit' in the wrong order. Rather than chasing down which callers need to pre-initialize reply, and whether there are any other uninitialized uses, it's easier to guarantee that reply will always be set by nbd_co_receive_one_chunk() even on failure. The uninitialized use happens to be harmless (the only time the variable is uninitialized is if s->quit is set, so the conditional results in the same action regardless of what was read from reply), and was introduced in commit 65e01d47. In fixing the problem, it can also be seen that all (one) callers pass in a non-NULL reply, so there is a dead conditional to also be cleaned up. Reported-by: Thomas Huth Reported-by: Andrey Shinkevich Signed-off-by: Eric Blake Message-Id: <20190719172001.19770-1-eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daud=C3=A9 --- block/nbd.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/block/nbd.c b/block/nbd.c index 81edabbf35ed..57c1a205811a 100644 --- a/block/nbd.c +++ b/block/nbd.c @@ -640,12 +640,11 @@ static coroutine_fn int nbd_co_receive_one_chunk( request_ret, qiov, payload, errp= ); if (ret < 0) { + memset(reply, 0, sizeof(*reply)); s->quit =3D true; } else { /* For assert at loop start in nbd_connection_entry */ - if (reply) { - *reply =3D s->reply; - } + *reply =3D s->reply; s->reply.handle =3D 0; } --=20 2.20.1