aboutsummaryrefslogtreecommitdiffstats
path: root/main/xen/xsa386.patch
diff options
context:
space:
mode:
Diffstat (limited to 'main/xen/xsa386.patch')
-rw-r--r--main/xen/xsa386.patch29
1 files changed, 29 insertions, 0 deletions
diff --git a/main/xen/xsa386.patch b/main/xen/xsa386.patch
new file mode 100644
index 0000000000..83f24d30d5
--- /dev/null
+++ b/main/xen/xsa386.patch
@@ -0,0 +1,29 @@
+From: Jan Beulich <jbeulich@suse.com>
+Subject: VT-d: fix deassign of device with RMRR
+Date: Fri, 1 Oct 2021 15:05:42 +0200
+
+Ignoring a specific error code here was not meant to short circuit
+deassign to _just_ the unmapping of RMRRs. This bug was previously
+hidden by the bogus (potentially indefinite) looping in
+pci_release_devices(), until f591755823a7 ("IOMMU/PCI: don't let domain
+cleanup continue when device de-assignment failed") fixed that loop.
+
+This is CVE-2021-28702 / XSA-386.
+
+Fixes: 8b99f4400b69 ("VT-d: fix RMRR related error handling")
+Reported-by: Ivan Kardykov <kardykov@tabit.pro>
+Signed-off-by: Jan Beulich <jbeulich@suse.com>
+Tested-by: Ivan Kardykov <kardykov@tabit.pro>
+
+--- a/xen/drivers/passthrough/vtd/iommu.c
++++ b/xen/drivers/passthrough/vtd/iommu.c
+@@ -2409,7 +2409,7 @@ static int reassign_device_ownership(
+ ret = iommu_identity_mapping(source, p2m_access_x,
+ rmrr->base_address,
+ rmrr->end_address, 0);
+- if ( ret != -ENOENT )
++ if ( ret && ret != -ENOENT )
+ return ret;
+ }
+ }
+