aboutsummaryrefslogtreecommitdiff
path: root/qmp.c
diff options
context:
space:
mode:
authorKevin Wolf <kwolf@redhat.com>2014-03-28 18:06:31 +0100
committerStefan Hajnoczi <stefanha@redhat.com>2014-04-01 15:21:03 +0200
commitb106ad9185f35fc4ad669555ad0e79e276083bd7 (patch)
tree180dbb92f35c3299780f066ec023266ab90bc508 /qmp.c
parent6d33e8e7dc9d40ea105feed4b39caa3e641569e8 (diff)
downloadqemu-b106ad9185f35fc4ad669555ad0e79e276083bd7.zip
qemu-b106ad9185f35fc4ad669555ad0e79e276083bd7.tar.gz
qemu-b106ad9185f35fc4ad669555ad0e79e276083bd7.tar.bz2
qcow2: Don't rely on free_cluster_index in alloc_refcount_block() (CVE-2014-0147)
free_cluster_index is only correct if update_refcount() was called from an allocation function, and even there it's brittle because it's used to protect unfinished allocations which still have a refcount of 0 - if it moves in the wrong place, the unfinished allocation can be corrupted. So not using it any more seems to be a good idea. Instead, use the first requested cluster to do the calculations. Return -EAGAIN if unfinished allocations could become invalid and let the caller restart its search for some free clusters. The context of creating a snapsnot is one situation where update_refcount() is called outside of a cluster allocation. For this case, the change fixes a buffer overflow if a cluster is referenced in an L2 table that cannot be represented by an existing refcount block. (new_table[refcount_table_index] was out of bounds) [Bump the qemu-iotests 026 refblock_alloc.write leak count from 10 to 11. --Stefan] Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Diffstat (limited to 'qmp.c')
0 files changed, 0 insertions, 0 deletions