Xen Security Advisory XSA-92
                              version 2

      HVMOP_set_mem_type allows invalid P2M entries to be created

UPDATES IN VERSION 2
====================

Public release.

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

The implementation in Xen of the HVMOP_set_mem_type HVM control
operations attempts to exclude transitioning a page from an
inappropriate memory type.  However, only an inadequate subset of
memory types is excluded.

There are certain other types that don't correspond to a particular
valid page, whose page table translation can be inappropriately
changed (by HVMOP_set_mem_type) from not-present (due to the lack of
valid memory page) to present.  If this occurs, an invalid translation
will be established.

IMPACT
======

In a configuration where device models run with limited privilege (for
example, stubdom device models), a guest attacker who successfully
finds and exploits an unfixed security flaw in qemu-dm could leverage
the other flaw into a Denial of Service affecting the whole host.

In the more general case, in more abstract terms: a malicious
administrator of a domain privileged with regard to an HVM guest can
cause Xen to crash leading to a Denial of Service.

Arbitrary code execution, and therefore privilege escalation, cannot
be entirely excluded: On a system with a RAM page present immediately
below the 52-bit address boundary, this would be possible.  However,
we are not aware of any systems with such a memory layout.

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

All Xen versions from 4.1 onwards are vulnerable.

The vulnerability is only exposed to service domains for HVM guests
which have privilege over the guest.  In a usual configuration that
means only device model emulators (qemu-dm).

In the case of HVM guests whose device model is running in an
unrestricted dom0 process, qemu-dm already has the ability to cause
problems for the whole system.  So in that case the vulnerability is
not applicable.

The situation is more subtle for an HVM guest with a stub qemu-dm.
That is, where the device model runs in a separate domain (in the case
of xl, as requested by "device_model_stubdomain_override=1" in the xl
domain configuration file).  The same applies with a qemu-dm in a dom0
process subjected to some kind kernel-based process privilege
limitation (eg the chroot technique as found in some versions of
XCP/XenServer).

In those latter situations this issue means that the extra isolation
does not provide as good a defence (against denial of service) as
intended.  That is the essence of this vulnerability.

However, the security is still better than with a qemu-dm running as
an unrestricted dom0 process.  Therefore users with these
configurations should not switch to an unrestricted dom0 qemu-dm.

Finally, in a radically disaggregated system: where the HVM service
domain software (probably, the device model domain image) is not
always supplied by the host administrator, a malicious service domain
administrator can exercise this vulnerability.

MITIGATION
==========

Running only PV guests will avoid this vulnerability.

In a radically disaggregated system, restricting HVM service domains
to software images approved by the host administrator will avoid the
vulnerability.

CREDITS
=======

This issue was discovered by Jan Beulich.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa92.patch                 xen-unstable, Xen 4.4.x, Xen 4.3.x
xsa92-4.2.patch             Xen 4.2.x
xsa92-4.1.patch             Xen 4.1.x

$ sha256sum xsa92*.patch
184dcb88dfb4540fca33016ffcfe0f4f557449ab5b4ec6a4bf486c75926d23f3  xsa92.patch
76905398958dfcec98fb5bde2a68c0e86a3ccc9f442a8a658e972937fd75534a  xsa92-4.1.patch
bca98827834f807c787fceb6c719d9d4fe3c40786cb087156829e5e6fb5700d6  xsa92-4.2.patch
$