Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Tue, 14 Mar 2017 12:00:34 +0000
From: security team <>
CC: security team <>
Subject: Xen Security Advisory 211 (CVE-2016-9603) - Cirrus VGA Heap
 overflow via display refresh

Hash: SHA1

            Xen Security Advisory CVE-2016-9603 / XSA-211
                              version 2

             Cirrus VGA Heap overflow via display refresh


Patches for qemu-xen-traditional.

Public release.


When a graphics update command gets passed to the VGA emulator, there
are 3 possible modes that can be used to update the display:

* blank - Clears the display
* text - Treats the display as showing text
* graph - Treats the display as showing graphics

After the display geometry gets changed (i.e., after the CIRRUS VGA
emulation has resized the display), the VGA emulator will resize the
console during the next update command. However, when a blank mode is
also selected during an update, this resize doesn't happen. The resize
will be properly handled during the next time a non-blank mode is
selected during an update.

However, other console components - such as the VNC emulation - will
operate as though this resize had happened. When the display is
resized to be larger than before, this can result in a heap overflow
as console components will expect the display buffer to be larger than
it is currently allocated.


A privileged user within the guest VM can cause a heap overflow in the
device model process, potentially escalating their privileges to that
of the device model process.


All versions of Xen are vulnerable.

Only HVM guests with the Cirrus video card are vulnerable.  (The
Cirrus video card is the default.)  Both qemu-upstream and
qemu-traditional are vulnerable.

For HVM guests with the device model running in a stub domain, "the
privileges of the device model process" are identical to those of the
guest kernel.  But the ability of a userspace process to trigger this
vulnerability via legitimate commands to the kernel driver (thus
elevating its privileges to that of the guest kernel) cannot be ruled


Running only PV guests, or running HVM guests with the stgvga driver,
will avoid this vulnerability.

Running HVM guests with stub domains will mitigate the vulnerability to
at most a guest kernel privilege escalation.


The discoverer of this issue requested to remain anonymous.


Applying the appropriate attached patch resolves this issue (and any
further bitblit vulnerabilities) by disabling the bitblit
functionality from the Cirrus VGA device entirely.

xsa211-qemuu.patch     qemu-upstream master
xsa211-qemuu-4.8.patch qemu-upstream 4.8
xsa211-qemuu-4.7.patch qemu-upstream 4.7
xsa211-qemuu-4.6.patch qemu-upstream 4.6 and 4.5
xsa211-qemuu-4.4.patch qemu-upstream 4.4
xsa211-qemut.patch     qemu-xen-traditional 4.6 and later
xsa211-qemut-4.5.patch qemu-xen-traditional 4.4 and 4.5

$ sha256sum xsa211*
9d0cf413dcc9654ee95f6b04fa9c5714f36775cbc9ab0390a3041ec4a68845ab  xsa211-qemut.patch
d307d67fbf3707a324da537e593702eaff3df2068b559ef19e857b493881155e  xsa211-qemut-4.5.patch
0fe17378cf2bc2742f068adf31331f36e01b0f4ffa9c596160fdba2bed3e870a  xsa211-qemuu.patch
1808aa443123d8713241a60021507a4d9c142c3cd07233e2f38e9b9b28025ae2  xsa211-qemuu-4.4.patch
5053c7cb392f34a234287092293bb91f261ed68f4b58fe856fe353b647ed5beb  xsa211-qemuu-4.6.patch
c5884bd441ae8cecce84385c99bcb72ba0eae480a013846fa59c1255aef4808f  xsa211-qemuu-4.7.patch
bea7cf4065bd9d0085f4dfc3395e59c3ca9d4de9d786a3018c8dc7fd9f3d8b6e  xsa211-qemuu-4.8.patch


The embargo period is much shorter than our standard two-week period.
This is at the request of the discoverer.


Deployment of the patches and/or the mitigation of running with an HVM
stub domain (or others which are substantially similar) is permitted
during the embargo, even on public-facing systems with untrusted guest
users and administrators.

It is NOT permitted during the embargo to switch from Cirrus VGA to
Stdvga on public-facing systems with untrusted guest users or
administrators.  This is because it may give a clue where the issue
lies.  This mitigation is only permitted AFTER the embargo ends.

As always, distribution of updated software is prohibited (except to
other members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
Version: GnuPG v1


Download attachment "xsa211-qemut.patch" of type "application/octet-stream" (8002 bytes)

Download attachment "xsa211-qemut-4.5.patch" of type "application/octet-stream" (8075 bytes)

Download attachment "xsa211-qemuu.patch" of type "application/octet-stream" (9903 bytes)

Download attachment "xsa211-qemuu-4.4.patch" of type "application/octet-stream" (10233 bytes)

Download attachment "xsa211-qemuu-4.6.patch" of type "application/octet-stream" (9821 bytes)

Download attachment "xsa211-qemuu-4.7.patch" of type "application/octet-stream" (9771 bytes)

Download attachment "xsa211-qemuu-4.8.patch" of type "application/octet-stream" (9852 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.