-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

            Xen Security Advisory CVE-2022-26356 / XSA-397
                               version 2

 Racy interactions between dirty vram tracking and paging log dirty hypercalls

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

Public release.

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

Activation of log dirty mode done by XEN_DMOP_track_dirty_vram (was named
HVMOP_track_dirty_vram before Xen 4.9) is racy with ongoing log dirty
hypercalls.  A suitably timed call to XEN_DMOP_track_dirty_vram can enable
log dirty while another CPU is still in the process of tearing down the
structures related to a previously enabled log dirty mode
(XEN_DOMCTL_SHADOW_OP_OFF).  This is due to lack of mutually exclusive locking
between both operations and can lead to entries being added in already freed
slots, resulting in a memory leak.

IMPACT
======

An attacker can cause Xen to leak memory, eventually leading to a Denial of
Service (DoS) affecting the entire host.

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

All Xen versions from at least 4.0 onwards are vulnerable.

Only x86 systems are vulnerable.  Arm systems are not vulnerable.

Only domains controlling an x86 HVM guest using Hardware Assisted Paging (HAP)
can leverage the vulnerability.  On common deployments this is limited to
domains that run device models on behalf of guests.

MITIGATION
==========

Using only PV or PVH guests and/or running HVM guests in shadow mode will avoid
the vulnerability.

CREDITS
=======

This issue was discovered by Roger Pau Monné of Citrix.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball.  Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.

xsa397.patch           xen-unstable
xsa397-4.16.patch      Xen 4.16.x - Xen 4.15.x
xsa397-4.14.patch      Xen 4.14.x - Xen 4.13.x
xsa397-4.12.patch      Xen 4.12.x

$ sha256sum xsa397*
49c663e2bb9131dbc2488e12487f79bdf0dafd51a32413cbf3964e39d8779cae  xsa397.patch
24f95f47b79739c9cb5b9110137c802989356c82d0aa27963b5ac7e33f667285  xsa397-4.12.patch
9af14f90ba10d074425eb6072a6c648082c92c1cf8b6f881f57ed2fc13d6e49d  xsa397-4.14.patch
ff5dd3b7a8dbf349c3b832b7916322c0296fa59c7f9cd2ba30858989add5f65c  xsa397-4.16.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches described above (or others which are substantially
similar) is permitted during the embargo, even on public-facing systems with
untrusted guest users and administrators.

But: Distribution of updated software (except to other members of the
predisclosure list) or deployment of mitigations is prohibited.

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.


(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmJMJDEMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZOUMH/RRZ8aMaoywqTV38SeTFne2tFT5jnWPPXR1ZGCvh
825hmSqzcYUaILbWFruUfT2PdpGoU9Eprz3xWXBDwgsUEGvKt7ZhGoWvxzXASlDh
cPRh/XwQVEEYsB1cRSk/GoLxLCQEV8oGNpmAcjEM4K1dG0VbVaRD0W2thNCmyPcv
d7aTkAdD2IE8NU4hX8YGN6v+UCkjrgzL0AF/hff9CMj7Sn/wBRrdStLT0LDZU20c
G/5+9nsOAVM7EwrzImI5Lx9KELyHwl37XUPffbftyTLUofdHJ5PK40J1tNIRS/RW
YYvs2alF7ng7LlwB/Go8gtn4XRx6xZidceYrUk22oB4JBqo=
=Fje3
-----END PGP SIGNATURE-----