diff --git a/xen.spec b/xen.spec index 324986b..2da35c3 100644 --- a/xen.spec +++ b/xen.spec @@ -58,7 +58,7 @@ Summary: Xen is a virtual machine monitor Name: xen Version: 4.14.3 -Release: 3%{?dist} +Release: 4%{?dist} License: GPLv2+ and LGPLv2+ and BSD URL: http://xen.org/ Source0: https://downloads.xenproject.org/release/xen/%{version}/xen-%{version}.tar.gz @@ -123,6 +123,10 @@ Patch52: xsa385-4.15.patch Patch53: xsa388-4.14-1.patch Patch54: xsa388-4.14-2.patch Patch55: xsa389-4.14.patch +Patch56: xsa376.patch +Patch57: xsa393.patch +Patch58: xsa394.patch +Patch59: xsa395-4.14.patch %if %build_qemutrad @@ -342,6 +346,10 @@ manage Xen virtual machines. %patch53 -p1 %patch54 -p1 %patch55 -p1 +%patch56 -p1 +%patch57 -p1 +%patch58 -p1 +%patch59 -p1 # qemu-xen-traditional patches pushd tools/qemu-xen-traditional @@ -948,6 +956,15 @@ fi %endif %changelog +* Tue Jan 25 2022 Michael Young - 4.14.3-4 +- frontends vulnerable to backends [XSA-376] (document change only) +- arm: guest_physmap_remove_page not removing the p2m mappings [XSA-393, + CVE-2022-23033] (#2045044) +- A PV guest could DoS Xen while unmapping a grant [XSA-394, CVE-2022-23034] + (#2045042) +- Insufficient cleanup of passed-through device IRQs [XSA-395, + CVE-2022-23035] (#2045040) + * Tue Nov 23 2021 Michael Young - 4.14.3-3 - guests may exceed their designated memory limit [XSA-385, CVE-2021-28706] - PoD operations on misaligned GFNs [XSA-388, CVE-2021-28704, CVE-2021-28707 diff --git a/xsa376.patch b/xsa376.patch new file mode 100644 index 0000000..08e0bff --- /dev/null +++ b/xsa376.patch @@ -0,0 +1,145 @@ +From 02d3a57d6466363b316b60ffbba414a4a2cb90c5 Mon Sep 17 00:00:00 2001 +From: Juergen Gross +Date: Thu, 25 Nov 2021 13:38:29 +0100 +Subject: [PATCH] SUPPORT.md: limit support statement for Linux and Windows + frontends + +Change the support state of Linux and Windows pv frontends from +"supported" to "supported with caveats" in order to reflect that the +frontends can probably be harmed by their respective backends. + +Some of the Linux frontends have been hardened already. + +This is XSA-376 + +Signed-off-by: Juergen Gross +--- + SUPPORT.md | 57 +++++++++++++++++++++++++++++++++++++++++++++--------- + 1 file changed, 48 insertions(+), 9 deletions(-) + +diff --git a/SUPPORT.md b/SUPPORT.md +index 3a34933c89..6e3e305b01 100644 +--- a/SUPPORT.md ++++ b/SUPPORT.md +@@ -411,7 +411,11 @@ Guest-side driver capable of speaking the Xen PV block protocol + Status, FreeBSD: Supported, Security support external + Status, NetBSD: Supported, Security support external + Status, OpenBSD: Supported, Security support external +- Status, Windows: Supported ++ Status, Windows: Supported, with caveats ++ ++Windows frontend currently trusts the backend; ++bugs in the frontend which allow backend to cause mischief will not be ++considered security vulnerabilities. + + ### Netfront + +@@ -421,20 +425,32 @@ Guest-side driver capable of speaking the Xen PV networking protocol + Status, FreeBSD: Supported, Security support external + Status, NetBSD: Supported, Security support external + Status, OpenBSD: Supported, Security support external +- Status, Windows: Supported ++ Status, Windows: Supported, with caveats ++ ++Windows frontend currently trusts the backend; ++bugs in the frontend which allow backend to cause mischief will not be ++considered security vulnerabilities. + + ### PV Framebuffer (frontend) + + Guest-side driver capable of speaking the Xen PV Framebuffer protocol + +- Status, Linux (xen-fbfront): Supported ++ Status, Linux (xen-fbfront): Supported, with caveats ++ ++Linux frontend currently trusts the backend; ++bugs in the frontend which allow backend to cause mischief will not be ++considered security vulnerabilities. + + ### PV display (frontend) + + Guest-side driver capable of speaking the Xen PV display protocol + +- Status, Linux: Supported (outside of "backend allocation" mode) +- Status, Linux: Experimental (in "backend allocation" mode) ++ Status, Linux, outside of "backend allocation" mode: Supported, with caveats ++ Status, Linux, "backend allocation" mode: Experimental ++ ++Linux frontend currently trusts the backend; ++bugs in the frontend which allow backend to cause mischief will not be ++considered security vulnerabilities. + + ### PV Console (frontend) + +@@ -443,7 +459,11 @@ Guest-side driver capable of speaking the Xen PV console protocol + Status, Linux (hvc_xen): Supported + Status, FreeBSD: Supported, Security support external + Status, NetBSD: Supported, Security support external +- Status, Windows: Supported ++ Status, Windows: Supported, with caveats ++ ++Windows frontend currently trusts the backend; ++bugs in the frontend which allow backend to cause mischief will not be ++considered security vulnerabilities. + + ### PV keyboard (frontend) + +@@ -451,11 +471,19 @@ Guest-side driver capable of speaking the Xen PV keyboard protocol. + Note that the "keyboard protocol" includes mouse / pointer / + multi-touch support as well. + +- Status, Linux (xen-kbdfront): Supported ++ Status, Linux (xen-kbdfront): Supported, with caveats ++ ++Linux frontend currently trusts the backend; ++bugs in the frontend which allow backend to cause mischief will not be ++considered security vulnerabilities. + + ### PV USB (frontend) + +- Status, Linux: Supported ++ Status, Linux: Supported, with caveats ++ ++Linux frontend currently trusts the backend; ++bugs in the frontend which allow backend to cause mischief will not be ++considered security vulnerabilities. + + ### PV SCSI protocol (frontend) + +@@ -464,6 +492,10 @@ multi-touch support as well. + NB that while the PV SCSI frontend is in Linux and tested regularly, + there is currently no xl support. + ++Linux frontend currently trusts the backend; ++bugs in the frontend which allow backend to cause mischief will not be ++considered security vulnerabilities. ++ + ### PV TPM (frontend) + + Guest-side driver capable of speaking the Xen PV TPM protocol +@@ -486,7 +518,11 @@ Guest-side driver capable of making pv system calls + + Guest-side driver capable of speaking the Xen PV sound protocol + +- Status, Linux: Supported ++ Status, Linux: Supported, with caveats ++ ++Linux frontend currently trusts the backend; ++bugs in the frontend which allow backend to cause mischief will not be ++considered security vulnerabilities. + + ## Virtual device support, host side + +@@ -987,6 +1023,9 @@ are given the following labels: + + This feature is security supported + by a different organization (not the XenProject). ++ The extent of support is defined by that organization. ++ It might be limited, e.g. like described in **Supported, with caveats** ++ below. + See **External security support** below. + + * **Supported, with caveats** +-- +2.26.2 + diff --git a/xsa393.patch b/xsa393.patch new file mode 100644 index 0000000..57af36b --- /dev/null +++ b/xsa393.patch @@ -0,0 +1,49 @@ +From 7ff58ab770157a03c92604155a0c745bcab834c2 Mon Sep 17 00:00:00 2001 +From: Julien Grall +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 +Fixes: 2148a125b73b ("xen/arm: Track page accessed between batch of Set/Way operations") +Reviewed-by: Stefano Stabellini +Signed-off-by: Julien Grall +--- + 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/xsa394.patch b/xsa394.patch new file mode 100644 index 0000000..1704c5b --- /dev/null +++ b/xsa394.patch @@ -0,0 +1,63 @@ +From a8bdee7a30d0cd13341d2ca1753569b171daf5b8 Mon Sep 17 00:00:00 2001 +From: Julien Grall +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 +Reviewed-by: Jan Beulich +--- + 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/xsa395-4.14.patch b/xsa395-4.14.patch new file mode 100644 index 0000000..488b15d --- /dev/null +++ b/xsa395-4.14.patch @@ -0,0 +1,42 @@ +From 743348f5d545c7fff9cdea746840b795f5c26d43 Mon Sep 17 00:00:00 2001 +From: Julien Grall +Date: Wed, 5 Jan 2022 18:09:39 +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 +Signed-off-by: Jan Beulich +Reviewed-by: Roger Pau Monné +--- + xen/drivers/passthrough/io.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c +index 71eaf2c17e27..b6e88ebc8646 100644 +--- a/xen/drivers/passthrough/io.c ++++ b/xen/drivers/passthrough/io.c +@@ -810,7 +810,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 +