Xen Security Advisory 394 v3 (CVE-2022-23034) - A PV guest could DoS Xen while unmapping a grant

[Xen.org security team <security@xxxxxxx>]

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

            Xen Security Advisory CVE-2022-23034 / XSA-394
                               version 3

           A PV guest could DoS Xen while unmapping a grant

UPDATES IN VERSION 3
====================

Public release.

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

To address XSA-380, reference counting was introduced for grant
mappings for the case where a PV guest would have the IOMMU enabled. PV
guests can request two forms of mappings.  When both are in use for any
individual mapping, unmapping of such a mapping can be requested in two
steps.  The reference count for such a mapping would then mistakenly be
decremented twice.  Underflow of the counters gets detected, resulting
in the triggering of a hypervisor bug check.

IMPACT
======

Malicious guest kernels may be able to mount a Denial of Service (DoS)
attack affecting the entire system.

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

All Xen versions from at least 3.2 onwards are vulnerable in principle,
if they have the XSA-380 fixes applied.

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

Only x86 PV guests with access to PCI devices can leverage the
vulnerability.  x86 HVM and PVH guests, as well as PV guests without
access to PCI devices, cannot leverage the vulnerability.

Additionally from Xen 4.13 onwards x86 PV guests can leverage this
vulnerability only when being granted access to pages owned by another
domain.

MITIGATION
==========

Not running PV guests will avoid the vulnerability.

For Xen 4.12 and older not passing through PCI devices to PV guests will
avoid the vulnerability.

For Xen 4.13 and newer not enabling PCI device pass-through for PV
guests will avoid the vulnerability.  This can be achieved via omitting
any "passthrough=..." and "pci=..." settings from xl guest configuration
files, or by setting "passthrough=disabled" there.

- From Xen 4.13 onwards, XSM SILO can be available as a security policy
designed to permit guests to only be able to communicate with Dom0.
Dom0 does not normally offer its pages for guests to map, which means
the use of SILO mode normally mitigates the vulnerability.

CREDITS
=======

This issue was discovered by Julien Grall of Amazon.

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.

xsa394.patch           xen-unstable - Xen 4.13.x
xsa394-4.12.patch      Xen 4.12.x

$ sha256sum xsa394*
93f4d3b58d49ba239115753c9905b7c3720b438c48ef8fb701f15081aa317159  xsa394.meta
f2a3420e8d3eb1cf728f90d3c352ace0d3c67f7933201ce9b784d63afaeaa179  xsa394.patch
ee93797546ac9e82f98211366f9acc733332b0d5ab7ef73840c2acd2bb1439ca  
xsa394-4.12.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.

HOWEVER, deployment of the mitigations described above is NOT permitted
during the embargo on public-facing systems with untrusted guest users
and administrators.  This is because such a configuration change is
recognizable by the affected guests.

AND: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

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/4UyVfoK9kFAmHv39IMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZfCYH/iZn73/JRTKI7B+9v2fW6v/k1IcVhpu+N4+TuRhh
Al5igmiTJLU3LcHM/H2KScgtnSwEKfCyddY1Gt3MZ+5lBDwR8elRkPdqn+P7xfol
4D5NgnEJDAYUWwJZOFn0qWfqNDnDkAvuKpm1zmv8RE0Xmw6a74Fvbfvi8PCuN9CO
zdippi5r5FlzFU7Q5MoWmOhmvVe3Fg7tGs4GXIyVUYkpDYyBGEWBo6rcoQ5aDvir
g8T0P1Y8XKCVvYM9SOdKWENppam0uIh00Mm+QDjQNaXD4I3DCDXLXkT7OGImZglr
MW8z5iNFjd0iXxFqTVBe1omxUhLC1xcB1fNySjd3zpt3RfA=
=mIA+
-----END PGP SIGNATURE-----

Attachment: xsa394.meta
Description: Binary data

Attachment: xsa394.patch
Description: Binary data

Attachment: xsa394-4.12.patch
Description: Binary data