A flaw was found in the way spice connection breakups were handled in the qemu-kvm qxl driver. Some of the qxl port i/o commands were waiting for the spice server to complete the actions, while the corresponding thread holds qemu_mutex mutex, potentially blocking other threads in the guest's qemu-kvm process. An user able to initiate spice connection to the guest could use this flaw to make guest temporarily unavailable or, in case kernel.softlockup_panic in the guest was set, crash the guest. Upstream fixes: xf86-video-qxl commit http://cgit.freedesktop.org/xorg/driver/xf86-video-qxl/commit/?id=30b4b72cdbdf9f0e92a8d1c4e01779f60f15a741 which relies on qemu-kvm functionality introduced by commit http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commit;h=5ff4e36c
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2013:0218 https://rhn.redhat.com/errata/RHSA-2013-0218.html
The fix isn't really a fix for all situations, since old drivers could be run in the guest and we don't prevent that from happening. On the other hand in second reading I don't think I agree with this being a CVE at all. Sure, the viewer app, which is remote, can cause the guest to be unresponsive, even to crash. But: 1. This is no different then running a faulty guest kernel, something a remote user can do already. 2. The viewer is part of the guest, i.e. it is treated as having permissions to do anything in the guest, if it should be verified then we use a password for that. This point overlaps point 1. 3. qemu doesn't crash in the process, the host isn't affected. Alon
(In reply to comment #2) > The fix isn't really a fix for all situations, since old drivers could be > run in the guest and we don't prevent that from happening. Right, but we document that the fix relies on qemu-kvm functionality in comment #0. > On the other hand in second reading I don't think I agree with this being a > CVE at all. Sure, the viewer app, which is remote, can cause the guest to be > unresponsive, even to crash. But: > ... Can the user have access to spice console and not be a guest administrator?
I see your point, it can be considered an elevation from a general spice console user to a guest administrator.(In reply to comment #3) > (In reply to comment #2) > > The fix isn't really a fix for all situations, since old drivers could be > > run in the guest and we don't prevent that from happening. > > Right, but we document that the fix relies on qemu-kvm functionality in > comment #0. > > > On the other hand in second reading I don't think I agree with this being a > > CVE at all. Sure, the viewer app, which is remote, can cause the guest to be > > unresponsive, even to crash. But: > > ... > > Can the user have access to spice console and not be a guest administrator? I see your point, it can be considered an elevation from a general spice console user to a guest administrator. Yes, what you describe is possible, I'm used to the situation where they are the same but probably it isn't common in an office deployment where there is a separate administrator.