]> git.ipfire.org Git - thirdparty/qemu.git/commit
block/qcow2: Fix corruption introduced by commit 8ac0f15f335
authorMaxim Levitsky <mlevitsk@redhat.com>
Sun, 15 Sep 2019 20:36:53 +0000 (23:36 +0300)
committerMax Reitz <mreitz@redhat.com>
Mon, 16 Sep 2019 13:35:02 +0000 (15:35 +0200)
commit38e7d54bdc518b5a05a922467304bcace2396945
tree9e154ed2f99212d5d64781e5208374e0e5687e3c
parentd876bf676f5e7c6aa9ac64555e48cba8734ecb2f
block/qcow2: Fix corruption introduced by commit 8ac0f15f335

This fixes subtle corruption introduced by luks threaded encryption
in commit 8ac0f15f335

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1745922

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
   * uses luks encryption

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 <mlevitsk@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20190915203655.21638-2-mlevitsk@redhat.com
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
block/qcow2-cluster.c