Frozen Windows 7 VMs with VGA CVE-2016-3712 fix (2.6.0 and 2.5.1.1)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Fix Released
|
Undecided
|
Unassigned | ||
qemu (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Trusty |
Fix Released
|
High
|
Marc Deslauriers | ||
Xenial |
Fix Released
|
High
|
Marc Deslauriers |
Bug Description
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 fd3c136b3e1482c
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: [bfc766d38e1fae
git bisect bad bfc766d38e1fae5
# good: [975eb6a547f809
git bisect good 975eb6a547f8096
# good: [2068192dcccd8a
git bisect good 2068192dcccd8a8
# bad: [53db932604dfa7
git bisect bad 53db932604dfa7b
# bad: [fd3c136b3e1482
git bisect bad fd3c136b3e1482c
# first bad commit: [fd3c136b3e1482
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-
Working installation:
./x86_64-
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://
Changed in qemu: | |
status: | New → Confirmed |
Changed in qemu: | |
status: | Confirmed → Fix Committed |
status: | Fix Committed → Confirmed |
no longer affects: | qemu (Fedora) |
Changed in qemu: | |
status: | Confirmed → Fix Committed |
tags: | added: regression-update |
Changed in qemu (Ubuntu Trusty): | |
assignee: | nobody → Marc Deslauriers (mdeslaur) |
Changed in qemu (Ubuntu Xenial): | |
assignee: | nobody → Marc Deslauriers (mdeslaur) |
Changed in qemu (Ubuntu): | |
importance: | Undecided → High |
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.