From nobody Wed Nov 12 07:08:23 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=1568388865; cv=none; d=zoho.com; s=zohoarc; b=SFzhHCU5vmskb7FnRMkSVv6ZJ+IvmHaBbWHecUop1nxGJlO1sGH79uJgC8ELOQKzeSI243z6sIX73aa4bUkyZ/Ku8vEG3WSuq2qj5lni8GiO+X+UmL5/d0WRVDXimVWAoqi4DYrcUlr+eCO4Hsf4GgjAxxMncIRneI2+0EneKbo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1568388865; h=Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=z4iXhR1yg2nnaVNbF9H4Tk2pAdz/zJ4bkaFZgwu+Lfk=; b=LgNvh+dokptaTJanj2pYeOISPWnFl4a3Rck8N3NvknKzj+9t/RN/jCZxrXZ4tE76GX3GmtS4rlJFrtInb/5ebFAuC8Qy1A61kjw9mzC2roLcyzOXdoVP4nPtNNLOAjppvlwJMKKG4sLh341HFWEX+L9hbS1QXRVlfg3NPdA8jpI= 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 (209.51.188.17 [209.51.188.17]) by mx.zohomail.com with SMTPS id 1568388865878584.4653679735695; Fri, 13 Sep 2019 08:34:25 -0700 (PDT) Received: from localhost ([::1]:45350 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i8naV-00072I-83 for importer@patchew.org; Fri, 13 Sep 2019 11:34:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53499) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i8nUx-0001K0-HH for qemu-devel@nongnu.org; Fri, 13 Sep 2019 11:28:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i8nUw-0004i9-CU for qemu-devel@nongnu.org; Fri, 13 Sep 2019 11:28:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54284) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i8nUr-0004gK-HK; Fri, 13 Sep 2019 11:28:29 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D62631DB0; Fri, 13 Sep 2019 15:28:28 +0000 (UTC) Received: from maximlenovopc.usersys.redhat.com (unknown [10.35.206.39]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7CBD55B681; Fri, 13 Sep 2019 15:28:23 +0000 (UTC) From: Maxim Levitsky To: qemu-devel@nongnu.org Date: Fri, 13 Sep 2019 18:28:16 +0300 Message-Id: <20190913152818.17843-2-mlevitsk@redhat.com> In-Reply-To: <20190913152818.17843-1-mlevitsk@redhat.com> References: <20190913152818.17843-1-mlevitsk@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.71]); Fri, 13 Sep 2019 15:28:28 +0000 (UTC) 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 v5 1/3] Fix qcow2+luks corruption introduced by commit 8ac0f15f335 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 , Vladimir Sementsov-Ogievskiy , =?UTF-8?q?Daniel=20P=20=2E=20Berrang=C3=A9?= , qemu-block@nongnu.org, qemu-stable , Max Reitz , Maxim Levitsky Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" This fixes subtle corruption introduced by luks threaded encryption in commit 8ac0f15f335 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=3D1745922 The corruption happens when we do a write that * writes to two or more unallocated clusters at once * doesn't fully cover the first sector * doesn't fully cover the last sector In this case, when allocating the new clusters we COW both areas prior to the write and after the write, and we encrypt them. The above mentioned commit accidentally made it so we encrypt the second COW area using the physical cluster offset of the first area. The problem is that offset_in_cluster in do_perform_cow_encrypt can be larger that the cluster size, thus cluster_offset will no longer point to the start of the cluster at which encrypted area starts. Next patch in this series will refactor the code to avoid all these assumptions. In the bugreport that was triggered by rebasing a luks image to new, zero filled base, which lot of such writes, and causes some files with zero areas to contain garbage there instead. But as described above it can happen elsewhere as well Signed-off-by: Maxim Levitsky Reviewed-by: Vladimir Sementsov-Ogievskiy --- block/qcow2-cluster.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c index dcacd3c450..bfeb0241d7 100644 --- a/block/qcow2-cluster.c +++ b/block/qcow2-cluster.c @@ -474,9 +474,10 @@ static bool coroutine_fn do_perform_cow_encrypt(BlockD= riverState *bs, assert((offset_in_cluster & ~BDRV_SECTOR_MASK) =3D=3D 0); assert((bytes & ~BDRV_SECTOR_MASK) =3D=3D 0); assert(s->crypto); - if (qcow2_co_encrypt(bs, cluster_offset, - src_cluster_offset + offset_in_cluster, - buffer, bytes) < 0) { + if (qcow2_co_encrypt(bs, + start_of_cluster(s, cluster_offset + offset_in_cluster), + src_cluster_offset + offset_in_cluster, + buffer, bytes) < 0) { return false; } } --=20 2.17.2