Bug 1397043 (CVE-2016-9637, xsa199) - CVE-2016-9637 XSA199 Xen: qemu ioport out-of-bounds array access (XSA-199)
Summary: CVE-2016-9637 XSA199 Xen: qemu ioport out-of-bounds array access (XSA-199)
Alias: CVE-2016-9637, xsa199
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1401521
Blocks: 1397044
TreeView+ depends on / blocked
Reported: 2016-11-21 13:16 UTC by Adam Mariš
Modified: 2021-10-21 11:47 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
An out of bounds array access issue was found in the Xen virtual machine monitor, built with the QEMU ioport support. It could occur while doing ioport read/write operations, if guest was to supply a 32bit address parameter. A privileged guest user/process could use this flaw to potentially escalate their privileges on a host.
Clone Of:
Last Closed: 2021-10-21 11:47:54 UTC

Attachments (Terms of Use)
qemu-xen-traditional patch (all versions) (2.79 KB, patch)
2016-11-21 13:23 UTC, Adam Mariš
no flags Details | Diff

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2963 0 normal SHIPPED_LIVE Important: xen security update 2016-12-20 20:25:55 UTC

Description Adam Mariš 2016-11-21 13:16:18 UTC

The code in qemu which implements ioport read/write looks up the
specified ioport address in a dispatch table.  The argument to the
dispatch function is a uint32_t, and is used without a range check,
even though the table has entries for only 2^16 ioports.

When qemu is used as a standalone emulator, ioport accesses are
generated only from cpu instructions emulated by qemu, and are
therefore necessarily 16-bit, so there is no vulnerability.

When qemu is used as a device model within Xen, io requests are
generated by the hypervisor and read by qemu from a shared ring.  The
entries in this ring use a common structure, including a 64-bit
address field, for various accesses, including ioport addresses.

Xen will write only 16-bit address ioport accesses.  However,
depending on the Xen and qemu version, the ring may be writeable by
the guest.  If so, the guest can generate out-of-range ioport
accesses, resulting in wild pointer accesses within qemu.


A malicious guest administrator can escalate their privilege to that
of the qemu process.


PV guests cannot exploit the vulnerability.

ARM systems are not vulnerable.

HVM domains run with QEMU stub domains cannot exploit the
vulnerability.  (A QEMU stub domain is used if xl's domain
configuration file contains "device_model_stubdomain_override=1".)

Guests using the modern "qemu-xen" device model, with a qemu version
of at least 1.6.0 (for example, as provided by the Xen Project in its
Xen 4.4.0 and later releases), cannot exploit the vulnerability.

x86 HVM guests, not configured with qemu stub domains, using a version
of qemu older than qemu upstream 1.6.0, can exploit the vulnerability.

x86 HVM guests using the traditional "qemu-xen-traditional", not
configured with qemu stub domains, can therefore exploit the

In tabular form:

Guest      Xen       QEMU    QEMU "traditional"            Status
type       version   stub      and/or qemu version

ARM        any       n/a     n/a         any               OK
x86 PV     any       n/a     n/a         any               OK

x86 HVM    any       yes     qemu-xen-traditional          OK

x86 HVM    any       no      qemu-xen*   >= 1.6.0          OK
x86 HVM    >= 4.4    no      qemu-xen*   Xen supplied      OK

x86 HVM    any       no      qemu-xen*   < 1.6.0           Vulnerable
x86 HVM    <= 4.3    no      qemu-xen*   Xen supplied      Vulnerable

x86 HVM    any       no      qemu-xen-traditional          Vulnerable

[*] qemu-xen is the default when qemu stub domains are not in
use, since Xen 4.3.


Enabling stubdomains will mitigate this issue, by reducing the
escalation to only those privileges accorded to the service domain.
In a usual configuration, a service domain has only the privilege of
the guest, so this eliminates the vulnerability.

Running HVM guests with the default upstream device model, in Xen 4.4
and later, will also avoid this vulnerability.

External References:



Name: the Xen project

Comment 1 Adam Mariš 2016-11-21 13:23:10 UTC
Created attachment 1222386 [details]
qemu-xen-traditional patch (all versions)

Comment 5 errata-xmlrpc 2016-12-20 15:26:09 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 5

Via RHSA-2016:2963 https://rhn.redhat.com/errata/RHSA-2016-2963.html

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