* Xen Security Advisory 383 v2 (CVE-2021-28700) - xen/arm: No memory limit for dom0less domUs
@ 2021-08-25 12:01 Xen.org security team
0 siblings, 0 replies; only message in thread
From: Xen.org security team @ 2021-08-25 12:01 UTC (permalink / raw)
To: xen-announce, xen-devel, xen-users, oss-security; +Cc: Xen.org security team
[-- Attachment #1: Type: text/plain, Size: 3257 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2021-28700 / XSA-383
version 2
xen/arm: No memory limit for dom0less domUs
UPDATES IN VERSION 2
====================
Public release.
ISSUE DESCRIPTION
=================
The dom0less feature allows an administrator to create multiple
unprivileged domains directly from Xen. Unfortunately, the
memory limit from them is not set. This allow a domain to allocate
memory beyond what an administrator originally configured.
IMPACT
======
Malicious dom0less guest could drive Xen out of memory and may
result to a Denial of Service (DoS) attack affecting the entire
system.
VULNERABLE SYSTEMS
==================
Only Arm systems are vulnerable. Only domains created using the
dom0less feature are affected.
Only domains created using the dom0less feature can leverage the
vulnerability.
All versions of Xen since 4.12 are vulnerable.
MITIGATION
==========
There is no known mitigation.
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.
xsa383.patch xen-unstable - Xen 4.13.x
xsa383-4.12.patch Xen 4.12.x
$ sha256sum xsa383*
773fe38d5d182ce43b5552fcdf6ed08c33126ed728e40d94c5050f89bfb3bd4d xsa383.meta
cfd0632d250cc36d88269ae08e19e742c6bd07ba130c2604d51a10ba64d4e413 xsa383.patch
d18f72fa595f330fa8ed13c9412a36fba58a8baf9ad30b9fc2fd4e4533c0ee1a xsa383-4.12.patch
$
DEPLOYMENT DURING EMBARGO
=========================
Deployment of the patches and/or mitigations 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 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/4UyVfoK9kFAmEmMPYMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZmboIALCcOpac8K7jPXZ+D5S5S1kGExOHYCLDBCZ6LyPt
jUmuR3r7xnkpJmcwSqGBHF5/PR6Sug+AjiggR8WHAFYiKod7yt1NjR4dm92Jy89x
t4mpyQ2ZX7PIMOiTfxlsmzsDspBxjk9sV6Pt7w4o25MiWdmY41hEkE+qtJ0OBto0
btzbaInKko6SXZWPGGpAToKlKPnwcApe2DehGYO98xl8eUZ8Ql/1lieHjuSK60Nx
RlboPeGDZwDgDroRj8GFNGxl2hESULVof0tG3w2IXPmYoa9iTKNUnO3KFL4kAJ/p
ZWzyRuHbX9FjQXBFnJJ5pyTHrc1aYzXJCwxAoSt436aRX2c=
=NGUO
-----END PGP SIGNATURE-----
[-- Attachment #2: xsa383.meta --]
[-- Type: application/octet-stream, Size: 1696 bytes --]
{
"XSA": 383,
"SupportedVersions": [
"master",
"4.15",
"4.14",
"4.13",
"4.12"
],
"Trees": [
"xen"
],
"Recipes": {
"4.12": {
"Recipes": {
"xen": {
"StableRef": "ea20eee97e9e0861127a8070cc7b9ae3557b09fb",
"Prereqs": [
378,
379,
380,
382
],
"Patches": [
"xsa383-4.12.patch"
]
}
}
},
"4.13": {
"Recipes": {
"xen": {
"StableRef": "32d580902b959000d79d51dff03a3560653c4fcb",
"Prereqs": [
378,
379,
380,
382
],
"Patches": [
"xsa383.patch"
]
}
}
},
"4.14": {
"Recipes": {
"xen": {
"StableRef": "49299c4813b7847d29df07bf790f5489060f2a9c",
"Prereqs": [
378,
379,
380,
382
],
"Patches": [
"xsa383.patch"
]
}
}
},
"4.15": {
"Recipes": {
"xen": {
"StableRef": "dba774896f7dd74773c14d537643b7d7477fefcd",
"Prereqs": [
378,
379,
380,
382
],
"Patches": [
"xsa383.patch"
]
}
}
},
"master": {
"Recipes": {
"xen": {
"StableRef": "25da9455f1bb8a6d33039575a7b28bdfc4e3fcfe",
"Prereqs": [
378,
379,
380,
382
],
"Patches": [
"xsa383.patch"
]
}
}
}
}
}
[-- Attachment #3: xsa383.patch --]
[-- Type: application/octet-stream, Size: 1859 bytes --]
From: Julien Grall <jgrall@amazon.com>
Date: Sat, 3 Jul 2021 14:03:36 +0100
Subject: [PATCH] xen/arm: Restrict the amount of memory that dom0less domU and
dom0 can allocate
Currently, both dom0less domUs and dom0 can allocate an "unlimited"
amount of memory because d->max_pages is set to ~0U.
In particular, the former are meant to be unprivileged. Therefore the
memory they could allocate should be bounded. As the domain are not yet
officially aware of Xen (we don't expose advertise it in the DT, yet
the hypercalls are accessible), they should not need to allocate more
than the initial amount. So cap set d->max_pages directly the amount of
memory we are meant to allocate.
Take the opportunity to also restrict the memory for dom0 as the
domain is direct mapped (e.g. MFN == GFN) and therefore cannot
allocate outside of the pre-allocated region.
This is CVE-2021-28700 / XSA-383.
Reported-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
---
xen/arch/arm/domain_build.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 6c86d527810f..206038d1c022 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2440,7 +2440,8 @@ static int __init construct_domU(struct domain *d,
if ( vcpu_create(d, 0) == NULL )
return -ENOMEM;
- d->max_pages = ~0U;
+
+ d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT;
kinfo.d = d;
@@ -2546,7 +2547,7 @@ static int __init construct_dom0(struct domain *d)
iommu_hwdom_init(d);
- d->max_pages = ~0U;
+ d->max_pages = dom0_mem >> PAGE_SHIFT;
kinfo.unassigned_mem = dom0_mem;
kinfo.d = d;
--
2.17.1
[-- Attachment #4: xsa383-4.12.patch --]
[-- Type: application/octet-stream, Size: 1855 bytes --]
From: Julien Grall <jgrall@amazon.com>
Date: Sat, 3 Jul 2021 14:03:36 +0100
Subject: [PATCH] xen/arm: Restrict the amount of memory that dom0less domU and
dom0 can allocate
Currently, both dom0less domUs and dom0 can allocate an "unlimited"
amount of memory because d->max_pages is set to ~0U.
In particular, the former are meant to be unprivileged. Therefore the
memory they could allocate should be bounded. As the domain are not yet
officially aware of Xen (we don't expose advertise it in the DT, yet
the hypercalls are accessible), they should not need to allocate more
than the initial amount. So cap set d->max_pages directly the amount of
memory we are meant to allocate.
Take the opportunity to also restrict the memory for dom0 as the
domain is direct mapped (e.g. MFN == GFN) and therefore cannot
allocate outside of the pre-allocated region.
This is CVE-2021-28700 / XSA-383.
Reported-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
---
xen/arch/arm/domain_build.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 6c5a6db14466..c3553ce4c49e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2028,7 +2028,8 @@ static int __init construct_domU(struct domain *d,
if ( vcpu_create(d, 0, 0) == NULL )
return -ENOMEM;
- d->max_pages = ~0U;
+
+ d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT;
kinfo.d = d;
@@ -2116,7 +2117,7 @@ int __init construct_dom0(struct domain *d)
iommu_hwdom_init(d);
- d->max_pages = ~0U;
+ d->max_pages = dom0_mem >> PAGE_SHIFT;
kinfo.unassigned_mem = dom0_mem;
kinfo.d = d;
--
2.17.1
^ permalink raw reply related [flat|nested] only message in thread
only message in thread, other threads:[~2021-08-25 12:02 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-25 12:01 Xen Security Advisory 383 v2 (CVE-2021-28700) - xen/arm: No memory limit for dom0less domUs Xen.org security team
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.