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

When accessing guest memory Xen does not correctly perform permissions
checks on the (possibly guest provided) virtual address: it only
checks that the mapping is readable by the guest, even when writing on
behalf of the guest.  This allows a guest to write to memory which
it should only be able to read.

A guest running on a vulnerable system is able to write to memory
which should be read-only.  This includes supposedly read only foreign
mappings established using the grant table mechanism.  Such read-only
mappings are commonly used as part of the paravirtualised I/O drivers
(such as guest disk write and network transmit).

In order to exploit this vulnerability the guest must have a mapping
of the memory; it does not allow access to arbitrary addresses.

In the event that a guest executes code from a page which has been
shared read-only with another guest it would be possible to mount a
take over attack on that guest.

IMPACT
======

A domain which is deliberately exchanging data with another,
malicious, domain, may be vulnerable to privilege escalation.  The
vulnerability depends on the precise behaviour of the victim domain.

In a typical configuration this means that, depending on the behaviour
of the toolstack or device driver domain, a malicious guest
administrator might be able to escalate their privilege to that of the
whole host.

VULNERABLE SYSTEMS
==================Both 32- and 64-bit ARM systems are vulnerable from Xen 4.4 onward.

MITIGATION
==========

None.

CREDITS
=======

This issue was discovered by Julien Grall.

RESOLUTION
==========

Applying the appropriate pair of attached patches resolves this issue.

xsa98-unstable-{01,02}.patch        xen-unstable
xsa98-4.4-{01,02}.patch             Xen 4.4.x