Xen supports disaggregation of various support and management
functions into their own domains; this is often done for security and
robustness reasons.

In Xen 4.3 additional functionality was introduced to allow further
disaggregation: the Xen Security Modules mechanism was enhanced to
make it possible to delegate all domctls (domain control hypercalls)
to particular other domains, rather than only permitting use by dom0.

However the domctl implementations were originally written to be used
only by the totally-privileged dom0, and have not been reviewed for
security when exposed to supposedly-only-semi-privileged disaggregated
management domains.  But such management domains are (in such a
design) to be seen as potentially hostile, e.g. due to privilege
escalation following exploitation of a bug in the management domain.

As a result, the potential security benefits of toolstack
disaggregation are not always fully realised.  This constitutes a
breach of the enhanced security promises implied by the Xen APIs in
Xen in 4.3 and later.

Domains deliberately given partial management control may be able to
deny service to the entire host or even escalate their privileges.

Acknowledgements:

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