[prev in list] [next in list] [prev in thread] [next in thread]
List: oss-security
Subject: [oss-security] Xen Security Advisory 394 v3 (CVE-2022-23034) - A PV guest could DoS Xen while unmapp
From: Xen.org security team <security () xen ! org>
Date: 2022-01-25 12:05:03
Message-ID: E1nCKZL-0003VD-3e () xenbits ! xenproject ! org
[Download RAW message or body]
-----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-----
["xsa394.meta" (application/octet-stream)]
["xsa394.patch" (application/octet-stream)]
From a8bdee7a30d0cd13341d2ca1753569b171daf5b8 Mon Sep 17 00:00:00 2001
From: Julien Grall <jgrall@amazon.com>
Date: Fri, 19 Nov 2021 11:27:47 +0000
Subject: [PATCH] xen/grant-table: Only decrement the refcounter when grant is
fully unmapped
The grant unmapping hypercall (GNTTABOP_unmap_grant_ref) is not a
simple revert of the changes done by the grant mapping hypercall
(GNTTABOP_map_grant_ref).
Instead, it is possible to partially (or even not) clear some flags.
This will leave the grant is mapped until a future call where all
the flags would be cleared.
XSA-380 introduced a refcounting that is meant to only be dropped
when the grant is fully unmapped. Unfortunately, unmap_common() will
decrement the refcount for every successful call.
A consequence is a domain would be able to underflow the refcount
and trigger a BUG().
Looking at the code, it is not clear to me why a domain would
want to partially clear some flags in the grant-table. But as
this is part of the ABI, it is better to not change the behavior
for now.
Fix it by checking if the maptrack handle has been released before
decrementing the refcounting.
This is CVE-2022-23034 / XSA-394.
Fixes: 9781b51efde2 ("gnttab: replace mapkind()")
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
xen/common/grant_table.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 0262f2c48af8..ed1e2fabcea6 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1488,8 +1488,15 @@ unmap_common(
if ( put_handle )
put_maptrack_handle(lgt, op->handle);
- /* See the respective comment in map_grant_ref(). */
- if ( rc == GNTST_okay && ld != rd && gnttab_need_iommu_mapping(ld) )
+ /*
+ * map_grant_ref() will only increment the refcount (and update the
+ * IOMMU) once per mapping. So we only want to decrement it once the
+ * maptrack handle has been put, alongside the further IOMMU update.
+ *
+ * For the second and third check, see the respective comment in
+ * map_grant_ref().
+ */
+ if ( put_handle && ld != rd && gnttab_need_iommu_mapping(ld) )
{
void **slot;
union maptrack_node node;
--
2.32.0
["xsa394-4.12.patch" (application/octet-stream)]
From 604fb691eee5bbeba770126451d880b932565e65 Mon Sep 17 00:00:00 2001
From: Julien Grall <jgrall@amazon.com>
Date: Wed, 5 Jan 2022 17:55:48 +0000
Subject: [PATCH] xen/grant-table: Only decrement the refcounter when grant is
fully unmapped
The grant unmapping hypercall (GNTTABOP_unmap_grant_ref) is not a
simple revert of the changes done by the grant mapping hypercall
(GNTTABOP_map_grant_ref).
Instead, it is possible to partially (or even not) clear some flags.
This will leave the grant is mapped until a future call where all
the flags would be cleared.
XSA-380 introduced a refcounting that is meant to only be dropped
when the grant is fully unmapped. Unfortunately, unmap_common() will
decrement the refcount for every successful call.
A consequence is a domain would be able to underflow the refcount
and trigger a BUG().
Looking at the code, it is not clear to me why a domain would
want to partially clear some flags in the grant-table. But as
this is part of the ABI, it is better to not change the behavior
for now.
Fix it by checking if the maptrack handle has been released before
decrementing the refcounting.
This is CVE-2022-23034 / XSA-394.
Fixes: 9781b51efde2 ("gnttab: replace mapkind()")
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
xen/common/grant_table.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index ee5748e74eb9..61d29df7bdf6 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1402,7 +1402,12 @@ unmap_common(
if ( put_handle )
put_maptrack_handle(lgt, op->handle);
- if ( rc == GNTST_okay && gnttab_need_iommu_mapping(ld) )
+ /*
+ * map_grant_ref() will only increment the refcount (and update the
+ * IOMMU) once per mapping. So we only want to decrement it once the
+ * maptrack handle has been put, alongside the further IOMMU update.
+ */
+ if ( put_handle && gnttab_need_iommu_mapping(ld) )
{
void **slot;
union maptrack_node node;
--
2.32.0
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic