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

xenstored supports transactions, such that if writes which would
invalidate assumptions of a transaction occur, the entire transaction
fails.  Typical response on a failed transaction is to simply retry
the transaction until it succeeds.

Unprivileged domains may issue writes to xenstore which conflict with
transactions either of the toolstack or of backends such as the driver
domain. Depending on the exact timing, repeated writes may cause
transactions made by these entities to fail indefinitely.

IMPACT
======

Unprivileged guests may be able to stall progress of the control
domain or driver domain, possibly leading to a Denial of Service (DoS)
of the entire host.

In most systems, the impact is limited to the delay or prevention of
control operations (such as domain creation, reconfiguration,
configuration enquiry, or destruction).

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

All Xen versions are vulnerable.

Both "cxenstored" (the version of xenstored written in C) and
"oxenstored" (the version of xenstored written in ocaml) are
vulnerable.  oxenstored in Xen 4.7 and later is more difficult to
exploit because it has more fine-grained detection of conflicts.

MITIGATION
==========

If the rogue domain(s) can be identified, it will usually be possible
to pause them with "xl pause" and/or destroy them with "xl destroy".
Note that if the toolstack is not simply "xl", the toolstack may be
confused by use of "xl" to pause or destroy domains.

The output of commands such as "xl top" and "xenstore-ls -fp" may be
helpful to find the rogue domain(s).

When the rogue domain(s) are paused or destroyed, the stuck operations
will become unstuck.

External References:

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

Acknowledgements:

Name: the Xen project