This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 906032 - (CVE-2013-0241) CVE-2013-0241 qxl: synchronous io guest DoS
CVE-2013-0241 qxl: synchronous io guest DoS
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20110803,repor...
: Security
Depends On: 871027 888364
Blocks: 906035 906069
  Show dependency treegraph
 
Reported: 2013-01-30 11:31 EST by Petr Matousek
Modified: 2014-09-07 19:03 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Petr Matousek 2013-01-30 11:31:25 EST
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 14:32:34 EST
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 02:44:02 EDT
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 04:35:14 EDT
(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 04:54:39 EDT
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.