Frozen Windows 7 VMs with VGA CVE-2016-3712 fix (2.6.0 and 2.5.1.1) Hi, As already posted on the QEMU devel list [1] I stumbled upon a problem with QEMU in version 2.5.1.1 and 2.6.0. the VM shows Windows loading files for the installation, then the "Starting Windows" screen appears here it hangs and never continues. Changing the "-vga" option to cirrus solves this, the installation can proceed and finish. When changing back to std (or also qxl, vmware) the installed VM also hangs on the "Starting Windows" screen while qemu showing a little but no excessive load. This phenomena appears also with QEMU 2.6.0 but not with 2.6.0-rc4, a git bisect shows fd3c136b3e1482cd0ec7285d6bc2a3e6a62c38d7 (vga: make sure vga register setup for vbe stays intact (CVE-2016-3712)) as the culprit for this regression, as its a fix for a DoS its not an option to just revert it, I guess. The bisect log is: git bisect start # bad: [bfc766d38e1fae5767d43845c15c79ac8fa6d6af] Update version for v2.6.0 release git bisect bad bfc766d38e1fae5767d43845c15c79ac8fa6d6af # good: [975eb6a547f809608ccb08c221552f666611af25] Update version for v2.6.0-rc4 release git bisect good 975eb6a547f809608ccb08c221552f666611af25 # good: [2068192dcccd8a80dddfcc8df6164cf9c26e0fc4] vga: update vga register setup on vbe changes git bisect good 2068192dcccd8a80dddfcc8df6164cf9c26e0fc4 # bad: [53db932604dfa7bb9241d132e0173894cf54261c] Merge remote-tracking branch 'remotes/kraxel/tags/pull-vga-20160509-1' into staging git bisect bad 53db932604dfa7bb9241d132e0173894cf54261c # bad: [fd3c136b3e1482cd0ec7285d6bc2a3e6a62c38d7] vga: make sure vga register setup for vbe stays intact (CVE-2016-3712). git bisect bad fd3c136b3e1482cd0ec7285d6bc2a3e6a62c38d7 # first bad commit: [fd3c136b3e1482cd0ec7285d6bc2a3e6a62c38d7] vga: make sure vga register setup for vbe stays intact (CVE-2016-3712). I could reproduce that with QEMU 2.5.1 and QEMU 2.6 on a Debian derivate (Promox VE) with 4.4 Kernel and also with QEMU 2.6 on an Arch Linux System with a 4.5 Kernel, so it should not be host distro depended. Both machines have Intel x86_64 processors. The problem should be reproducible with said Versions or a build from git including the above mentioned commit (fd3c136) by starting a VM with an Windows 7 ISO, e.g.: Freezing installation (as vga defaults to std I marked it as optional): ./x86_64-softmmu/qemu-system-x86_64 -boot d -cdrom win7.iso -m 1024 [-vga (std|qxl|vmware)] Working installation: ./x86_64-softmmu/qemu-system-x86_64 -boot d -cdrom win7.iso -m 1024 -vga cirrus If someone has already an installed Windows 7 VM this behaviour should be also observable when trying to start it with the new versions of QEMU. Noteworthy may be that Windows 10 is working, I do not had time to get other Windows versions and test them, I'll do that as soon as possible. Various Linux system also seems do work fine, at least I did not ran into an issue there yet. I also tried testing with SeaBIOS and OVMF as firmware, as initially I had no idea what broke, both lead to the same result - without the CVE-2016-3712 fix they both work, with not. Further, KVM enabled and disabled does not make any difference. [1] http://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg02416.html I can confirm this behaviour. Tested on 3 different machines, all Windows 7 VMs are broke because of the latest "patch". Also tested Windows XP and Windows 10, both work with VGA flawlessly. I experience the same behavior on RHEL 7.2 since I installed the lastest patch. Seem to be a RHEL/Fedora on the same issue: https://bugzilla.redhat.com/show_bug.cgi?id=1339267 supposed to be fixed by , please confirm I can partly confirm this, see (and parents): https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg04048.html It sounds just a little strange to me, so I'll recheck to be double sure every configure option is the same on my Arch Linux and Debian machine. I'm experiencing the same issue. Terrible video performance with Cirrus as it is the only video workable with windows 7. Please, fix it. So this is fixed upstream, in Fedora and ARCH. Can we expect a fix for xenial? This is quite a show stopper. Commit 94ef4f337fb614f18b7 has been released with QEMU version 2.7 Will the fix be backported? Right now, this is a regression in xenial (caused by the security update in 1:2.5+dfsg-5ubuntu10.6). ... and trusty is affected, too. Would it help if I provide patches for trusty/xenial? I'd probably also need to update the description for SRU? Please let me know if there is anything I can do to help get these patches accepted for trusty/xenial. The attachment "Proposed fix for trusty" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team. [This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.] Hi, thanks for marking Qemu(Ubuntu) so I could see it - and thanks for the prework on the patches. We need to clear a few in progress SRUs before that but other than that things look nice. We can work on the patches a bit until that happened. We will need somewhat proper Dep3 headers in [1] the patches - I can add those if you want me to do so. [1]: http://dep.debian.net/deps/dep3/ I checked and this is in 2.6.1 via a backport as [1] not as the original [2]. But that means >=Yakkety is good and Xenial/Trusty are bad since the related Security SRUs. Updating bug tasks accordingly. [1]: http://git.qemu.org/?p=qemu.git;a=commit;h=7ff5dc445d6bb392f9fb3d0a254ef9071304780b [2]: http://git.qemu.org/?p=qemu.git;a=commit;h=94ef4f337fb614f18b765a8e0e878a4c23cdedcd Discussed with the Security Team, this will very likely be in the next round of updates that will follow soon. I'll additionally ping the release team to get the blocking ongoing SRU processed faster. This bug was fixed in the package qemu - 2.0.0+dfsg-2ubuntu1.34 --------------- qemu (2.0.0+dfsg-2ubuntu1.34) trusty-security; urgency=medium * SECURITY UPDATE: denial of service via leak in virtFS - debian/patches/CVE-2017-7377.patch: fix file descriptor leak in hw/9pfs/virtio-9p.c. - CVE-2017-7377 * SECURITY UPDATE: denial of service in cirrus_vga - debian/patches/CVE-2017-7718.patch: check parameters in hw/display/cirrus_vga_rop.h. - CVE-2017-7718 * SECURITY UPDATE: code execution via cirrus_vga OOB r/w - debian/patches/CVE-2017-7980-1.patch: handle negative pitch in hw/display/cirrus_vga.c. - debian/patches/CVE-2017-7980-2.patch: allow zero source pitch in hw/display/cirrus_vga.c. - debian/patches/CVE-2017-7980-3.patch: fix blit address mask handling in hw/display/cirrus_vga.c. - debian/patches/CVE-2017-7980-4.patch: fix patterncopy checks in hw/display/cirrus_vga.c. - debian/patches/CVE-2017-7980-5.patch: revert allow zero source pitch in hw/display/cirrus_vga.c. - debian/patches/CVE-2017-7980-6.patch: stop passing around dst pointers in hw/display/cirrus_vga.c, hw/display/cirrus_vga_rop.h, hw/display/cirrus_vga_rop2.h. - debian/patches/CVE-2017-7980-7.patch: stop passing around src pointers in hw/display/cirrus_vga.c, hw/display/cirrus_vga_rop.h, hw/display/cirrus_vga_rop2.h. - debian/patches/CVE-2017-7980-8.patch: fix off-by-one in hw/display/cirrus_vga_rop.h. - debian/patches/CVE-2017-7980-9.patch: fix cirrus_invalidate_region in hw/display/cirrus_vga.c. - CVE-2017-7980 * SECURITY UPDATE: denial of service via memory leak in virtFS - debian/patches/CVE-2017-8086.patch: fix leak in hw/9pfs/virtio-9p-xattr.c. - CVE-2017-8086 * SECURITY UPDATE: denial of service via leak in audio - debian/patches/CVE-2017-8309.patch: release capture buffers in audio/audio.c. - CVE-2017-8309 * SECURITY UPDATE: denial of service via leak in keyboard - debian/patches/CVE-2017-8379-1.patch: limit kbd queue depth in ui/input.c. - debian/patches/CVE-2017-8379-2.patch: don't queue delay if paused in ui/input.c. - CVE-2017-8379 * SECURITY REGRESSION: Windows 7 VGA compatibility issue (LP: #1581936) - debian/patches/lp1581936.patch: add sr_vbe register set to hw/display/vga.c, hw/display/vga_int.h. -- Marc Deslauriers