xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* Xen Security Advisory 369 v2 (CVE-2021-28039) - Linux: special config may crash when trying to map foreign pages
@ 2021-03-05 17:07 Xen.org security team
  0 siblings, 0 replies; only message in thread
From: Xen.org security team @ 2021-03-05 17:07 UTC (permalink / raw)
  To: xen-announce, xen-devel, xen-users, oss-security; +Cc: Xen.org security team

[-- Attachment #1: Type: text/plain, Size: 3001 bytes --]

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

            Xen Security Advisory CVE-2021-28039 / XSA-369
                              version 2

   Linux: special config may crash when trying to map foreign pages

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

CVE assigned.

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

With CONFIG_XEN_BALLOON_MEMORY_HOTPLUG disabled and
CONFIG_XEN_UNPOPULATED_ALLOC enabled the Linux kernel will use guest
physical addresses allocated via the ZONE_DEVICE functionality for
mapping foreign guest's pages.

This will result in problems, as the p2m list will only cover the initial
memory size of the domain plus some padding at the end. Most ZONE_DEVICE
allocated addresses will be outside the p2m range and thus a mapping can't
be established with those memory addresses, resulting in a crash.

The attack involves doing I/O requiring large amounts of data to be
mapped by the Dom0 or driver domain.  The amount of data needed to
result in a crash can vary depending on the memory layout of the
affected Dom0 or driver domain.

IMPACT
======

A Dom0 or driver domain based on a Linux kernel (configured as
described above) can be crashed by a malicious guest administrator, or
possibly malicious unprivileged guest processes.

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

Only x86 paravirtualized (PV) Dom0 or driver domains are
affected.

Only Linux kernels configured *with* CONFIG_XEN_UNPOPULATED_ALLOC and
*without* CONFIG_XEN_BALLOON_MEMORY_HOTPLUG are vulnerable.  Only
kernels from kernel version 5.9 onwards are affected.

CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is enabled by default in upstream
Linux when Xen support is enabled, so kernels using upstream default
Kconfig are not affected.  Most distribution kernels supporting Xen
dom0 use are likewise not vulnerable.

Arm systems or x86 PVH or x86 HVM driver domains are not affected.

MITIGATION
==========

There is no mitigation available.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa369-linux.patch           Linux 5.9-stable - 5.12-rc

$ sha256sum xsa369*
937df4f078a070cf47bdd718c6b8a042ec6bee255eedc422d833c2ae3dd561c7  xsa369-linux.patch
$

CREDITS
=======

This issue was discovered by Marek Marczykowski-Górecki of Invisible
Things Lab.

For patch:
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

NOTE REGARDING LACK OF EMBARGO
==============================

This was reported publicly multiple times, before the XSA could be
issued.
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmBCZVUMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZp8wIALvuzrh0iQDIg86Mx/eTtfVflmrz91YiDPfhrDj1
L1D2lR+uFPKFpb3CdDTlzKoby/1ym4wbTLCjnDdXxjmPTdn4KybcBNbNONt2p69X
dr/3KsO6yW5tjSi3FRZnnyTnTJN/q65tijG23sAcF7KuNW+xT2d70tWMH+LeMQZO
fGkztK08cZspFfZZiOJHuqi5qpzoaBw7/vqlCphoiDMeE1EOGpaa/+bGb4doehyj
dN8dyEWbyWdTp5lAxmduJfDMuixeESIxPnXP8jV3Z9b+Gt5l9S0cM+DCWDRUkW3M
W0Z7va35sFLCx4+N7fLuzMUkzoLWpTJq2i2m9lploexe3nY=
=PtNk
-----END PGP SIGNATURE-----

[-- Attachment #2: xsa369-linux.patch --]
[-- Type: application/octet-stream, Size: 5098 bytes --]

From: Juergen Gross <jgross@suse.com>
Subject: xen: fix p2m size in dom0 for disabled memory hotplug case

Since commit 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated
memory") foreign mappings are using guest physical addresses allocated
via ZONE_DEVICE functionality.

This will result in problems for the case of no balloon memory hotplug
being configured, as the p2m list will only cover the initial memory
size of the domain. Any ZONE_DEVICE allocated address will be outside
the p2m range and thus a mapping can't be established with that memory
address.

Fix that by extending the p2m size for that case. At the same time add
a check for a to be created mapping to be within the p2m limits in
order to detect errors early.

While changing a comment, remove some 32-bit leftovers.

This is XSA-369.

Fixes: 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated memory")
Cc: <stable@vger.kernel.org> # 5.9
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/page.h | 12 ++++++++++++
 arch/x86/xen/p2m.c              | 10 ++++++----
 arch/x86/xen/setup.c            | 25 +++----------------------
 3 files changed, 21 insertions(+), 26 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 1a162e559753..7068e4bb057d 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -86,6 +86,18 @@ clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
 }
 #endif
 
+/*
+ * The maximum amount of extra memory compared to the base size.  The
+ * main scaling factor is the size of struct page.  At extreme ratios
+ * of base:extra, all the base memory can be filled with page
+ * structures for the extra memory, leaving no space for anything
+ * else.
+ *
+ * 10x seems like a reasonable balance between scaling flexibility and
+ * leaving a practically usable system.
+ */
+#define XEN_EXTRA_MEM_RATIO	(10)
+
 /*
  * Helper functions to write or read unsigned long values to/from
  * memory, when the access may fault.
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 9545b8df5315..ed3585eebc4e 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -416,6 +416,9 @@ void __init xen_vmalloc_p2m_tree(void)
 	xen_p2m_last_pfn = xen_max_p2m_pfn;
 
 	p2m_limit = (phys_addr_t)P2M_LIMIT * 1024 * 1024 * 1024 / PAGE_SIZE;
+	if (!p2m_limit && IS_ENABLED(CONFIG_XEN_UNPOPULATED_ALLOC))
+		p2m_limit = xen_start_info->nr_pages * XEN_EXTRA_MEM_RATIO;
+
 	vm.flags = VM_ALLOC;
 	vm.size = ALIGN(sizeof(unsigned long) * max(xen_max_p2m_pfn, p2m_limit),
 			PMD_SIZE * PMDS_PER_MID_PAGE);
@@ -652,10 +655,9 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 	pte_t *ptep;
 	unsigned int level;
 
-	if (unlikely(pfn >= xen_p2m_size)) {
-		BUG_ON(mfn != INVALID_P2M_ENTRY);
-		return true;
-	}
+	/* Only invalid entries allowed above the highest p2m covered frame. */
+	if (unlikely(pfn >= xen_p2m_size))
+		return mfn == INVALID_P2M_ENTRY;
 
 	/*
 	 * The interface requires atomic updates on p2m elements.
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 7eab14d56369..1a3b75652fa4 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -59,18 +59,6 @@ static struct {
 } xen_remap_buf __initdata __aligned(PAGE_SIZE);
 static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY;
 
-/* 
- * The maximum amount of extra memory compared to the base size.  The
- * main scaling factor is the size of struct page.  At extreme ratios
- * of base:extra, all the base memory can be filled with page
- * structures for the extra memory, leaving no space for anything
- * else.
- * 
- * 10x seems like a reasonable balance between scaling flexibility and
- * leaving a practically usable system.
- */
-#define EXTRA_MEM_RATIO		(10)
-
 static bool xen_512gb_limit __initdata = IS_ENABLED(CONFIG_XEN_512GB);
 
 static void __init xen_parse_512gb(void)
@@ -790,20 +778,13 @@ char * __init xen_memory_setup(void)
 		extra_pages += max_pages - max_pfn;
 
 	/*
-	 * Clamp the amount of extra memory to a EXTRA_MEM_RATIO
-	 * factor the base size.  On non-highmem systems, the base
-	 * size is the full initial memory allocation; on highmem it
-	 * is limited to the max size of lowmem, so that it doesn't
-	 * get completely filled.
+	 * Clamp the amount of extra memory to a XEN_EXTRA_MEM_RATIO
+	 * factor the base size.
 	 *
 	 * Make sure we have no memory above max_pages, as this area
 	 * isn't handled by the p2m management.
-	 *
-	 * In principle there could be a problem in lowmem systems if
-	 * the initial memory is also very large with respect to
-	 * lowmem, but we won't try to deal with that here.
 	 */
-	extra_pages = min3(EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM)),
+	extra_pages = min3(XEN_EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM)),
 			   extra_pages, max_pages - max_pfn);
 	i = 0;
 	addr = xen_e820_table.entries[0].addr;
-- 
2.26.2


^ permalink raw reply related	[flat|nested] only message in thread

only message in thread, other threads:[~2021-03-05 17:08 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-05 17:07 Xen Security Advisory 369 v2 (CVE-2021-28039) - Linux: special config may crash when trying to map foreign pages Xen.org security team

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).