Bug 906032 (CVE-2013-0241) - CVE-2013-0241 qxl: synchronous io guest DoS
Summary: CVE-2013-0241 qxl: synchronous io guest DoS
Keywords:
Status: NEW
Alias: CVE-2013-0241
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 871027 888364
Blocks: 906035 906069
TreeView+ depends on / blocked
 
Reported: 2013-01-30 16:31 UTC by Petr Matousek
Modified: 2019-09-29 12:59 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0218 normal SHIPPED_LIVE Moderate: xorg-x11-drv-qxl security update 2013-02-01 00:23:25 UTC

Description Petr Matousek 2013-01-30 16:31:25 UTC
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

Comment 1 errata-xmlrpc 2013-01-31 19:32:34 UTC
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

Comment 2 Alon Levy 2013-04-18 06:44:02 UTC
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

Comment 3 Petr Matousek 2013-04-24 08:35:14 UTC
(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?

Comment 4 Alon Levy 2013-04-24 08:54:39 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.