Ian Jackson discovered that accesses beyond end of qemu emulated disk devices can result in accesses to emulator's virtual memory space accesses and thus can allow user with sufficient privilege in guest (root, as this would need modification to kernel's driver) to break out of VM. http://marc.info/?l=debian-security&m=120343592917055&w=2
qemu-0.9.0-6.fc8 has been submitted as an update for Fedora 8
qemu-0.9.0-4.fc7 has been submitted as an update for Fedora 7
kvm-60-2.fc8 has been submitted as an update for Fedora 8
kvm-36-8.fc7 has been submitted as an update for Fedora 7
kvm-36-8.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
kvm-60-2.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
qemu-0.9.0-6.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
qemu-0.9.0-4.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
Created attachment 296005 [details] A revised version of range checking patch The original patch adds checks to the main bdrv_XXX apis to validate that the I/O operation does not exceed the bounds of the disk - ie beyond the total_sectors count. This works correctly for bdrv_XXX calls from the IDE driver. With disk formats like QCow though, bdrv_XXX is re-entrant, because the QCow driver uses the block APIs for dealing with its underlying file. The problem is that QCow files are grow-on-demand, so writes will *explicitly* be beyond the end of the file. The original patch blocks any I/O operation which would cause the QCow file to grow, resulting it more or less catasatrophic data loss. Basically the bounds checking needs to distinguish between checking for the logical disk extents, vs the physical disk extents. For raw files these are the same so initial tests showed no problems, but for QCow format disks they are different & thus we see a problem What follows is a revised patch which introduces a flag BDRV_O_AUTOGROW which can be passed to bdrv_open to indicate that the files can be allowed to automatically extend their extents. This flag should only be used by internal block drivers such as block-qcow2.c, block-vmdk.c In my testing this has fixed the qcow corruption, and still maintains the goal of Ian's original patch which was to prevent the guest VM writing beyond the logical disk extents.
xen-3.1.2-2.fc8 has been submitted as an update for Fedora 8
xen-3.1.2-2.fc7 has been submitted as an update for Fedora 7
xen-3.1.2-2.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
xen-3.1.2-2.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
During the follow-up of bug #496041 we noticed that snapshot support in qcow2 is still broken after fixing the qcow2 corruption bugs upstream. I bisected the breakage to the kvm-0013-Fix-CVE-2008-0928-insufficient-block-device-addres.patch which is the patch to address this bug. Running the following commands creates and destroys a qcow2 image: qemu-img create -f qcow2 test.qcow2 10M qemu-img info test.qcow2 qemu-img snapshot -c test0 test.qcow2 qemu-img info test.qcow2 The reason this patch breaks snapshots is obvious: The VM state is saved after the end of the visible guest disk and such accesses are prevented now. I'm not sure yet why it breaks the image instead of failing gracefully. Upstream qemu has a different fix by now, so we might consider to pull that one instead.
Created attachment 341538 [details] New patch, backported from upstream qemu The attached patch should be considered as a replacement for our current patch. I have completely reverted our patch which was previously rejected by upstream qemu and backported the upstream fix (which is this patch) which can handle snapshots without destroying the image.
Reporter changed to security-response-team by request of Jay Turner.
This was addressed via: Red Hat Enterprise Linux version 5 (RHSA-2008:0194) RHEL Virtualization version 5 (RHSA-2008:0194)