Script 'mail_helper' called by obssrc Hello community, here is the log from the commit of package xen for openSUSE:Factory checked in at 2022-01-27 23:16:27 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comparing /work/SRC/openSUSE:Factory/xen (Old) and /work/SRC/openSUSE:Factory/.xen.new.1898 (New) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "xen" Thu Jan 27 23:16:27 2022 rev:311 rq:949116 version:4.16.0_04 Changes: -------- --- /work/SRC/openSUSE:Factory/xen/xen.changes 2022-01-13 00:22:32.451937599 +0100 +++ /work/SRC/openSUSE:Factory/.xen.new.1898/xen.changes 2022-01-27 23:16:44.727069963 +0100 @@ -1,0 +2,21 @@ +Thu Jan 13 10:55:58 MST 2022 - [email protected] + +- bsc#1194576 - VUL-0: CVE-2022-23033: xen: arm: + guest_physmap_remove_page not removing the p2m mappings (XSA-393) + xsa393.patch +- bsc#1194581 - VUL-0: CVE-2022-23034: xen: a PV guest could DoS + Xen while unmapping a grant (XSA-394) + xsa394.patch +- bsc#1194588 - VUL-0: CVE-2022-23035: xen: insufficient cleanup of + passed-through device IRQs (XSA-395) + xsa395.patch + +------------------------------------------------------------------- +Wed Jan 12 14:16:53 MST 2022 - [email protected] + +- bsc#1191668 - L3: issue around xl and virsh operation - virsh + list not giving any output + libxl-dont-try-to-free-a-NULL-list-of-vcpus.patch + libxl-dont-touch-nr_vcpus_out-if-listing-vcpus-and-returning-NULL.patch + +------------------------------------------------------------------- New: ---- libxl-dont-touch-nr_vcpus_out-if-listing-vcpus-and-returning-NULL.patch libxl-dont-try-to-free-a-NULL-list-of-vcpus.patch xsa393.patch xsa394.patch xsa395.patch ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ xen.spec ++++++ --- /var/tmp/diff_new_pack.BvXlHj/_old 2022-01-27 23:16:46.467057942 +0100 +++ /var/tmp/diff_new_pack.BvXlHj/_new 2022-01-27 23:16:46.471057914 +0100 @@ -160,6 +160,9 @@ Patch3: 61bc429f-revert-hvmloader-PA-range-should-be-UC.patch Patch4: 61d5687a-x86-spec-ctrl-opt_srb_lock-default.patch # EMBARGOED security fixes +Patch11: xsa393.patch +Patch12: xsa394.patch +Patch13: xsa395.patch # libxc Patch301: libxc-bitmap-long.patch Patch302: libxc-sr-xl-migration-debug.patch @@ -222,6 +225,8 @@ Patch468: libxl.helper_done-crash.patch Patch469: libxl.LIBXL_HOTPLUG_TIMEOUT.patch Patch470: libxl-Fix-PV-hotplug-and-stubdom-coldplug.patch +Patch471: libxl-dont-try-to-free-a-NULL-list-of-vcpus.patch +Patch472: libxl-dont-touch-nr_vcpus_out-if-listing-vcpus-and-returning-NULL.patch # python3 conversion patches Patch500: build-python3-conversion.patch Patch501: migration-python3-conversion.patch ++++++ libxl-dont-touch-nr_vcpus_out-if-listing-vcpus-and-returning-NULL.patch ++++++ References: bsc#1191668, bsc#1194267 If we are in libvxl_list_vcpu() and we are returning NULL, let's avoid touching the output parameter *nr_vcpus_out (which should contain the number of vcpus in the list). Ideally, the caller initialized it to 0, which is therefore consistent with us returning NULL (or, as an alternative, we can explicitly set it to 0 if we're returning null... But just not touching it seems the best behavior). In fact, the current behavior is especially problematic if, for instance, a domain is destroyed after we have done some steps of the for() loop. In which case, calls like xc_vcpu_getinfo() or xc_vcpu_getaffinity() will start to fail, and we return back to the caller inconsistent information, such as a NULL list of vcpus, but a modified and not 0 any longer, number of vcpus in the list. Signed-off-by: Dario Faggioli <dfaggioli@xxxxxxxx> Tested-by: James Fehlig <jfehlig@xxxxxxxx> --- Cc: Wei Liu <wl@xxxxxxx> Cc: Anthony PERARD <anthony.perard@xxxxxxxxxx> Cc: Juergen Gross <jgross@xxxxxxxx> --- tools/libs/light/libxl_domain.c | 14 ++++++++------ tools/libs/light/libxl_numa.c | 4 +++- 2 files changed, 11 insertions(+), 7 deletions(-) --- a/tools/libs/light/libxl_domain.c +++ b/tools/libs/light/libxl_domain.c @@ -1680,6 +1680,7 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ct libxl_vcpuinfo *ptr, *ret; xc_domaininfo_t domaininfo; xc_vcpuinfo_t vcpuinfo; + int nr_vcpus; if (xc_domain_getinfolist(ctx->xch, domid, 1, &domaininfo) != 1) { LOGED(ERROR, domid, "Getting infolist"); @@ -1696,27 +1697,27 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ct ret = ptr = libxl__calloc(NOGC, domaininfo.max_vcpu_id + 1, sizeof(libxl_vcpuinfo)); - for (*nr_vcpus_out = 0; - *nr_vcpus_out <= domaininfo.max_vcpu_id; - ++*nr_vcpus_out, ++ptr) { + for (nr_vcpus = 0; + nr_vcpus <= domaininfo.max_vcpu_id; + ++nr_vcpus, ++ptr) { libxl_bitmap_init(&ptr->cpumap); if (libxl_cpu_bitmap_alloc(ctx, &ptr->cpumap, 0)) goto err; libxl_bitmap_init(&ptr->cpumap_soft); if (libxl_cpu_bitmap_alloc(ctx, &ptr->cpumap_soft, 0)) goto err; - if (xc_vcpu_getinfo(ctx->xch, domid, *nr_vcpus_out, &vcpuinfo) == -1) { + if (xc_vcpu_getinfo(ctx->xch, domid, nr_vcpus, &vcpuinfo) == -1) { LOGED(ERROR, domid, "Getting vcpu info"); goto err; } - if (xc_vcpu_getaffinity(ctx->xch, domid, *nr_vcpus_out, + if (xc_vcpu_getaffinity(ctx->xch, domid, nr_vcpus, ptr->cpumap.map, ptr->cpumap_soft.map, XEN_VCPUAFFINITY_SOFT|XEN_VCPUAFFINITY_HARD) == -1) { LOGED(ERROR, domid, "Getting vcpu affinity"); goto err; } - ptr->vcpuid = *nr_vcpus_out; + ptr->vcpuid = nr_vcpus; ptr->cpu = vcpuinfo.cpu; ptr->online = !!vcpuinfo.online; ptr->blocked = !!vcpuinfo.blocked; @@ -1724,6 +1725,7 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ct ptr->vcpu_time = vcpuinfo.cpu_time; } GC_FREE; + *nr_vcpus_out = nr_vcpus; return ret; err: --- a/tools/libs/light/libxl_numa.c +++ b/tools/libs/light/libxl_numa.c @@ -219,8 +219,10 @@ static int nr_vcpus_on_nodes(libxl__gc * goto next; vinfo = libxl_list_vcpu(CTX, dinfo[i].domid, &nr_dom_vcpus, &nr_cpus); - if (vinfo == NULL) + if (vinfo == NULL) { + assert(nr_dom_vcpus == 0); goto next; + } /* Retrieve the domain's node-affinity map */ libxl_domain_get_nodeaffinity(CTX, dinfo[i].domid, &dom_nodemap); ++++++ libxl-dont-try-to-free-a-NULL-list-of-vcpus.patch ++++++ References: bsc#1191668, bsc#1194267 If libxl_vcpu_list() returned NULL, we should not call libxl_numainfo_list_free() as: 1) it'll fail trying to (double) free() *list 2) there should be nothing to free anyway Signed-off-by: Dario Faggioli <dfaggioli@xxxxxxxx> Tested-by: James Fehlig <jfehlig@xxxxxxxx> --- Cc: Wei Liu <wl@xxxxxxx> Cc: Anthony PERARD <anthony.perard@xxxxxxxxxx> Cc: Juergen Gross <jgross@xxxxxxxx> --- tools/libs/light/libxl_numa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libs/light/libxl_numa.c b/tools/libs/light/libxl_numa.c index a8a75f89e9..3679028c79 100644 --- a/tools/libs/light/libxl_numa.c +++ b/tools/libs/light/libxl_numa.c @@ -253,9 +253,9 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo, } } + libxl_vcpuinfo_list_free(vinfo, nr_dom_vcpus); next: libxl_cpupoolinfo_dispose(&cpupool_info); - libxl_vcpuinfo_list_free(vinfo, nr_dom_vcpus); } libxl_bitmap_dispose(&dom_nodemap); ++++++ xsa393.patch ++++++ >From 7ff58ab770157a03c92604155a0c745bcab834c2 Mon Sep 17 00:00:00 2001 From: Julien Grall <[email protected]> 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. Fixes: 2148a125b73b ("xen/arm: Track page accessed between batch of Set/Way operations") Reviewed-by: Stefano Stabellini <[email protected]> Signed-off-by: Julien Grall <[email protected]> --- 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 ++++++ xsa394.patch ++++++ >From a8bdee7a30d0cd13341d2ca1753569b171daf5b8 Mon Sep 17 00:00:00 2001 From: Julien Grall <[email protected]> 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 <[email protected]> Reviewed-by: Jan Beulich <[email protected]> --- 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 ++++++ xsa395.patch ++++++ >From 4cc924c3e3a0d53306d08b04720c427d1c298ba8 Mon Sep 17 00:00:00 2001 From: Julien Grall <[email protected]> Date: Wed, 5 Jan 2022 18:09:20 +0000 Subject: [PATCH] passthrough/x86: pt_pirq_iterate: Don't clobber rc in case of an 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 <[email protected]> Signed-off-by: Jan Beulich <[email protected]> Reviewed-by: Roger Pau Monn?? <[email protected]> --- 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
