summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorbill-auger <mr.j.spam.me@gmail.com>2022-04-03 16:12:17 -0400
committerbill-auger <mr.j.spam.me@gmail.com>2022-04-03 16:21:37 -0400
commit848886d6e6d72d34d1b922384f64f5efe58443c3 (patch)
tree1c1a768deec03a689cd6b0e86ff63f8de70d3b2d
parent7a1bb990a57534759265f37fc1c688057201ed9c (diff)
[xen]: avoid publishing 'any' docs package to 32-bit repos
-rw-r--r--pcr/xen/PKGBUILD13
-rw-r--r--pcr/xen/xsa393.patch49
-rw-r--r--pcr/xen/xsa394.patch63
-rw-r--r--pcr/xen/xsa395.patch42
4 files changed, 161 insertions, 6 deletions
diff --git a/pcr/xen/PKGBUILD b/pcr/xen/PKGBUILD
index 80b0f5022..ae6e2a6c6 100644
--- a/pcr/xen/PKGBUILD
+++ b/pcr/xen/PKGBUILD
@@ -23,7 +23,7 @@ pkgbase=xen
pkgname=("xen" "xen-docs")
pkgver=4.16.0
pkgrel=3
-pkgdesc='Open-source type-1 or baremetal hypervisor'
+pkgdesc='Type-1 or bare-metal hypervisor'
arch=('x86_64')
url='https://xenproject.org/'
license=('GPL2')
@@ -53,10 +53,11 @@ validpgpkeys=('23E3222C145F4475FA8060A783FE14C957E82BD9') # Xen.org Xen tree cod
# Follow the Xen securite mailing lists, and if a patch is applicable to our package
# add the URL here.
+# Better yet, add the patch to abslibre :)
_patches=(
- "https://xenbits.xen.org/xsa/xsa393.patch"
- "https://xenbits.xen.org/xsa/xsa394.patch"
- "https://xenbits.xen.org/xsa/xsa395.patch"
+ "xsa393.patch"
+ "xsa394.patch"
+ "xsa395.patch"
)
@@ -210,7 +211,7 @@ build() {
}
package_xen() {
- pkgdesc='Open-source type-1 or baremetal hypervisor'
+ pkgdesc='Type-1 or baremetal hypervisor'
depends=(
'zlib' 'python' 'ncurses' 'openssl' 'libx11' 'libuuid.so' 'yajl' 'libaio' 'glib2' 'pkgconf'
@@ -320,7 +321,7 @@ package_xen() {
package_xen-docs() {
pkgdesc="Xen hypervisor documentation and man pages"
- arch=("any")
+ arch=("x86_64") # no reason to publish this package to 32-bit repos
cd "${pkgbase}-${pkgver}"
make "${_common_make_flags[@]}" DESTDIR="$pkgdir" install-docs
}
diff --git a/pcr/xen/xsa393.patch b/pcr/xen/xsa393.patch
new file mode 100644
index 000000000..57af36bae
--- /dev/null
+++ b/pcr/xen/xsa393.patch
@@ -0,0 +1,49 @@
+From 7ff58ab770157a03c92604155a0c745bcab834c2 Mon Sep 17 00:00:00 2001
+From: Julien Grall <jgrall@amazon.com>
+Date: Tue, 14 Dec 2021 09:53:44 +0000
+Subject: [PATCH] xen/arm: p2m: Always clear the P2M entry when the mapping is
+ removed
+
+Commit 2148a125b73b ("xen/arm: Track page accessed between batch of
+Set/Way operations") allowed an entry to be invalid from the CPU PoV
+(lpae_is_valid()) but valid for Xen (p2m_is_valid()). This is useful
+to track which page is accessed and only perform an action on them
+(e.g. clean & invalidate the cache after a set/way instruction).
+
+Unfortunately, __p2m_set_entry() is only zeroing the P2M entry when
+lpae_is_valid() returns true. This means the entry will not be zeroed
+if the entry was valid from Xen PoV but invalid from the CPU PoV for
+tracking purpose.
+
+As a consequence, this will allow a domain to continue to access the
+page after it was removed.
+
+Resolve the issue by always zeroing the entry if it the LPAE bit is
+set or the entry is about to be removed.
+
+This is CVE-2022-23033 / XSA-393.
+
+Reported-by: Dmytro Firsov <Dmytro_Firsov@epam.com>
+Fixes: 2148a125b73b ("xen/arm: Track page accessed between batch of Set/Way operations")
+Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
+Signed-off-by: Julien Grall <jgrall@amazon.com>
+---
+ xen/arch/arm/p2m.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
+index 8b20b430777e..fb71fa4c1c90 100644
+--- a/xen/arch/arm/p2m.c
++++ b/xen/arch/arm/p2m.c
+@@ -1016,7 +1016,7 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
+ * sequence when updating the translation table (D4.7.1 in ARM DDI
+ * 0487A.j).
+ */
+- if ( lpae_is_valid(orig_pte) )
++ if ( lpae_is_valid(orig_pte) || removing_mapping )
+ p2m_remove_pte(entry, p2m->clean_pte);
+
+ if ( removing_mapping )
+--
+2.32.0
+
diff --git a/pcr/xen/xsa394.patch b/pcr/xen/xsa394.patch
new file mode 100644
index 000000000..1704c5b08
--- /dev/null
+++ b/pcr/xen/xsa394.patch
@@ -0,0 +1,63 @@
+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
+
diff --git a/pcr/xen/xsa395.patch b/pcr/xen/xsa395.patch
new file mode 100644
index 000000000..13b731102
--- /dev/null
+++ b/pcr/xen/xsa395.patch
@@ -0,0 +1,42 @@
+From 4cc924c3e3a0d53306d08b04720c427d1c298ba8 Mon Sep 17 00:00:00 2001
+From: Julien Grall <jgrall@amazon.com>
+Date: Wed, 5 Jan 2022 18:09:20 +0000
+Subject: [PATCH] passthrough/x86: stop pirq iteration immediately in case of
+ error
+
+pt_pirq_iterate() will iterate in batch over all the PIRQs. The outer
+loop will bail out if 'rc' is non-zero but the inner loop will continue.
+
+This means 'rc' will get clobbered and we may miss any errors (such as
+-ERESTART in the case of the callback pci_clean_dpci_irq()).
+
+This is CVE-2022-23035 / XSA-395.
+
+Fixes: c24536b636f2 ("replace d->nr_pirqs sized arrays with radix tree")
+Fixes: f6dd295381f4 ("dpci: replace tasklet with softirq")
+Signed-off-by: Julien Grall <jgrall@amazon.com>
+Signed-off-by: Jan Beulich <jbeulich@suse.com>
+Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
+---
+ xen/drivers/passthrough/x86/hvm.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/xen/drivers/passthrough/x86/hvm.c b/xen/drivers/passthrough/x86/hvm.c
+index 351daafdc9bf..0b37cd145b60 100644
+--- a/xen/drivers/passthrough/x86/hvm.c
++++ b/xen/drivers/passthrough/x86/hvm.c
+@@ -732,7 +732,11 @@ int pt_pirq_iterate(struct domain *d,
+
+ pirq = pirqs[i]->pirq;
+ if ( (pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
++ {
+ rc = cb(d, pirq_dpci, arg);
++ if ( rc )
++ break;
++ }
+ }
+ } while ( !rc && ++pirq < d->nr_pirqs && n == ARRAY_SIZE(pirqs) );
+
+--
+2.32.0
+