ISSUE DESCRIPTION
=================

"qemu-xen-traditional" (aka qemu-dm) tracks state for each MSI-X table
entry of a passed through device.  This is used/updated on
(intercepted) accesses to the page(s) containing the MSI-X table.

There may be space on the final page not covered by any MSI-X table
entry, but memory for state tracking is allocated only for existing
table entries.  Therefore bounds checks are required to avoid
accessing/corrupting unrelated heap memory.  Such a check is present
for the read path, but was missing for the write path.

IMPACT
======

A malicious administrator of a guest which has access to a passed
through PCI device which is MSI-X capable can exploit this
vulnerability to take over the qemu process, elevating its privilege
to that of the qemu process.

In a system not using a device model stub domain (or other techniques
for deprivileging qemu), the malicious guest administrator can thus
elevate their privilege to that of the host.

VULNERABLE SYSTEMS
==================

Xen systems running x86 HVM guests with "qemu-xen-traditional", but
without stubdomains, which have been passed through an MSI-X capable
physical PCI device are vulnerable.

The default configuration is NOT vulnerable from Xen 4.3 onwards
(because it uses a newer upstream qemu version).

Systems running only PV guests are NOT vulnerable.

Only systems using PCI passthrough are vulnerable.

Systems using "qemu-xen-traditional" stubdomain device models (for
example, by specifying "device_model_stubdomain_override=1" in xl's
domain configuration files) are NOT vulnerable.

Only the traditional "qemu-xen-traditional" device model is vulnerable.
Upstream qemu device models ("qemu-xen") are NOT vulnerable.

ARM systems are NOT vulnerable.

MITIGATION
==========

Not passing through MSI-X capable devices to HVM guests will avoid this
vulnerability.

Running HVM guests with the default upstream device model will also
avoid this vulnerability.

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.

External References:

http://xenbits.xen.org/xsa/advisory-164.html

Acknowledgements:

Red Hat would like to thank the Xen project for reporting this issue.