Bug 906032 (CVE-2013-0241)

Summary:	CVE-2013-0241 qxl: synchronous io guest DoS
Product:	[Other] Security Response	Reporter:	Petr Matousek <pmatouse>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	airlied, cfergeau, hdegoede, kem, marcandre.lureau, xgl-maint
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-10-19 22:00:07 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	871027, 888364
Bug Blocks:	906035, 906069

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.