-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2022-23034 / XSA-394
A PV guest could DoS Xen while unmapping a grant
UPDATES IN VERSION 3
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.
Malicious guest kernels may be able to mount a Denial of Service (DoS)
attack affecting the entire system.
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
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.
This issue was discovered by Julien Grall of Amazon.
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*
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
(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:
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
Created xen tracking bugs for this issue:
Affects: fedora-all [bug 2045042]
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):