An issue was discovered in Xen through 4.9.x allowing HVM guest OS users to gain privileges on the host OS, obtain sensitive information, or cause a denial of service (BUG and host OS crash) by leveraging the mishandling of Populate on Demand (PoD) Physical-to-Machine (P2M) errors.

The remote OracleVM system is missing necessary patches to address security updates:

  - An issue was discovered in Xen through 4.9.x allowing HVM guest OS users to cause a denial of service     (infinite loop and host OS hang) by leveraging the mishandling of Populate on Demand (PoD) errors.
    (CVE-2017-17044)

  - An issue was discovered in Xen through 4.9.x allowing HVM guest OS users to gain privileges on the host     OS, obtain sensitive information, or cause a denial of service (BUG and host OS crash) by leveraging the     mishandling of Populate on Demand (PoD) Physical-to-Machine (P2M) errors. (CVE-2017-17045)

  - issues with partially successful P2M updates on x86 T[his CNA information record relates to multiple CVEs;
    the text explains which aspects/vulnerabilities correspond to which CVE.] x86 HVM and PVH guests may be     started in populate-on-demand (PoD) mode, to provide a way for them to later easily have more memory     assigned. Guests are permitted to control certain P2M aspects of individual pages via hypercalls. These     hypercalls may act on ranges of pages specified via page orders (resulting in a power-of-2 number of     pages). In some cases the hypervisor carries out the requests by splitting them into smaller chunks. Error     handling in certain PoD cases has been insufficient in that in particular partial success of some     operations was not properly accounted for. There are two code paths affected - page removal     (CVE-2021-28705) and insertion of new pages (CVE-2021-28709). (We provide one patch which combines the fix     to both issues.) (CVE-2021-28705, CVE-2021-28709)

  - guests may exceed their designated memory limit When a guest is permitted to have close to 16TiB of     memory, it may be able to issue hypercalls to increase its memory allocation beyond the administrator     established limit. This is a result of a calculation done with 32-bit precision, which may overflow. It     would then only be the overflowed (and hence small) number which gets compared against the established     upper bound. (CVE-2021-28706)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote OracleVM system is missing necessary patches to address critical security updates : please see Oracle VM Security Advisory OVMSA-2020-0039 for details.

Multiple vulnerabilities have been discovered in the Xen hypervisor, which could result in denial of service, informations leaks or privilege escalation.

For Debian 8 'Jessie', these problems have been fixed in version 4.4.4lts3-0+deb8u1.

We recommend that you upgrade your xen packages.

NOTE: Tenable Network Security has extracted the preceding description block directly from the DLA security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

The remote OracleVM system is missing necessary patches to address critical security updates : please see Oracle VM Security Advisory OVMSA-2018-0248 for details.

The remote host is affected by the vulnerability described in GLSA-201801-14 (Xen: Multiple vulnerabilities)

    Multiple vulnerabilities have been discovered in Xen. Please review the       referenced CVE identifiers for details.
  Impact :

    A local attacker could potentially execute arbitrary code with the       privileges of the Xen (QEMU) process on the host, gain privileges on the       host system, or cause a Denial of Service condition.
  Workaround :

    There is no known workaround at this time.

xen: various flaws (#1518214) x86: infinite loop due to missing PoD error checking [XSA-246] Missing p2m error checking in PoD code [XSA-247]

Note that Tenable Network Security has extracted the preceding description block directly from the Fedora update system website.
Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

The remote OracleVM system is missing necessary patches to address critical security updates : please see Oracle VM Security Advisory OVMSA-2018-0005 for details.

Multiple vulnerabilities have been discovered in the Xen hypervisor, which could result in denial of service, information leaks, privilege escalation or the execution of arbitrary code.

For Debian 7 'Wheezy', these problems have been fixed in version 4.1.6.lts1-11.

We recommend that you upgrade your xen packages.

NOTE: Tenable Network Security has extracted the preceding description block directly from the DLA security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

another patch related to the [XSA-240, CVE-2017-15595] issue xen:
various flaws (#1525018) x86 PV guests may gain access to internally used page [XSA-248] broken x86 shadow mode refcount overflow check [XSA-249] improper x86 shadow mode refcount error handling [XSA-250] improper bug check in x86 log-dirty handling [XSA-251]

----

xen: various flaws (#1518214) x86: infinite loop due to missing PoD error checking [XSA-246] Missing p2m error checking in PoD code [XSA-247]

Note that Tenable Network Security has extracted the preceding description block directly from the Fedora update system website.
Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

The remote OracleVM system is missing necessary patches to address critical security updates :

  - From 2a99aa99fc84a45f505f84802af56b006d14c52e Mon Sep 17     00:00:00 2001 From: Andrew Cooper Date: Fri, 19 Aug 2016     15:08:10 +0100 Subject: [PATCH] xen/physmap: Do not     permit a guest to populate PoD pages for itself PoD is     supposed to be entirely transparent to guest, but this     interface has been left exposed for a long time. The use     of PoD requires careful co-ordination by the toolstack     with the XENMEM_[get,set]_pod_target hypercalls, and     xenstore ballooning target. The best a guest can do     without toolstack cooperation crash. Furthermore, there     are combinations of features (e.g. c/s c63868ff 'libxl:
    disallow PCI device assignment for HVM guest when PoD is     enabled') which a toolstack might wish to explicitly     prohibit (in this case, because the two simply don't     function in combination). In such cases, the guest     mustn't be able to subvert the configuration chosen by     the toolstack.

    Conflict: xen/common/memory.c

  - Due to the history performance reason, we decide to     disable PoD feature in old OVM product. Please don't set     maxmem>memory XSA-246,XSA-247 [bug 27120669]     (CVE-2017-17044, CVE-2017-17045)

  - x86/shadow: correct SH_LINEAR mapping detection in     sh_guess_wrmap The fix for XSA-243 / CVE-2017-15592 (c/s     bf2b4eadcf379) introduced a change in behaviour for     sh_guest_wrmap, where it had to cope with no shadow     linear mapping being present. As the name suggests,     guest_vtable is a mapping of the guests pagetable, not     Xen's pagetable, meaning that it isn't the pagetable we     need to check for the shadow linear slot in. The     practical upshot is that a shadow HVM vcpu which     switches into 4-level paging mode, with an L4 pagetable     that contains a mapping which aliases Xen's     SH_LINEAR_PT_VIRT_START will fool the safety check for     whether a SHADOW_LINEAR mapping is present. As the check     passes (when it should have failed), Xen subsequently     falls over the missing mapping with a pagefault such as:
    (XEN) Pagetable walk from ffff8140a0503880: (XEN)     L4[0x102] = 000000046c218063 ffffffffffffffff (XEN)     L3[0x102] = 000000046c218063 ffffffffffffffff (XEN)     L2[0x102] = 000000046c218063 ffffffffffffffff (XEN)     L1[0x103] = 0000000000000000 ffffffffffffffff This is     part of XSA-243. (CVE-2017-15592)

  - dpci: Fix a race during unbinding of MSI interrupt The     check of hvm_irq_dpci->mapping and read of flags are not     protected in same critical area, so the unbind of MSI     interrupt may intercepts between them. Like below scene:
    CPU0 CPU1

    ---- ---- hvm_do_IRQ_dpci !test_bit(mirq,     dpci->mapping)) return 0  spin_lock(&d->event_lock)     hvm_irq_dpci->mirq[machine_gsi].flags = 0     clear_bit(machine_gsi, hvm_irq_dpci->mapping)     spin_unlock(&d->event_lock)  <SoftIRQ> hvm_dirq_assist     spin_lock(&d->event_lock)  if (     pt_irq_need_timer(hvm_irq_dpci->mirq[pirq].flags))     set_timer  spin_unlock(&d->event_lock)  Then set_timer     is mistakenly called which access uninitialized timer     struct. Then page fault happen and a backtrace like     below: (XEN) Xen call trace: (XEN) [<ffff82c480124c92>]     set_timer+0x92/0x170 (XEN) [<ffff82c48013bb03>]     hvm_dirq_assist+0x1c3/0x1e0 (XEN) [<ffff82c4801235ff>]     do_tasklet_work_percpu+0x7f/0x120 (XEN)     [<ffff82c480121915>] __do_softirq+0x65/0x90 (XEN)     [<ffff82c4801f7fb6>] process_softirqs+0x6/0x10 (XEN)     (XEN) Pagetable walk from 0000000000000008: (XEN)     L4[0x000] = 0000002104cc1067 0000000000289430 (XEN)     L3[0x000] = 000000212ecd8067 00000000002b3447 (XEN)     L2[0x000] = 0000000000000000 ffffffffffffffff (XEN)     (XEN) **************************************** (XEN)     Panic on CPU 41: (XEN) FATAL PAGE FAULT (XEN)     [error_code=0002] (XEN) Faulting linear address:
    0000000000000008 (XEN)
    **************************************** This issue is     OVM3.2 only as OVM3.3 or above already has similar fix     in pt_pirq_iterate

The remote OracleVM system is missing necessary patches to address critical security updates :

  - Due to the history performance reason, we decide to     disable PoD feature in old OVM product.XSA-246,XSA-247     [bug 27121016] (CVE-2017-17044, CVE-2017-17045)

  - From 2a99aa99fc84a45f505f84802af56b006d14c52e Mon Sep 17     00:00:00 2001 From: Andrew Cooper Date: Fri, 19 Aug 2016     15:08:10 +0100 Subject: [PATCH] xen/physmap: Do not     permit a guest to populate PoD pages for itself PoD is     supposed to be entirely transparent to guest, but this     interface has been left exposed for a long time. The use     of PoD requires careful co-ordination by the toolstack     with the XENMEM_[get,set]_pod_target hypercalls, and     xenstore ballooning target. The best a guest can do     without toolstack cooperation crash. Furthermore, there     are combinations of features (e.g. c/s c63868ff 'libxl:
    disallow PCI device assignment for HVM guest when PoD is     enabled') which a toolstack might wish to explicitly     prohibit (in this case, because the two simply don't     function in combination). In such cases, the guest     mustn't be able to subvert the configuration chosen by     the toolstack.

    Conflict: xen/common/memory.c

  - x86/shadow: correct SH_LINEAR mapping detection in     sh_guess_wrmap The fix for XSA-243 / CVE-2017-15592 (c/s     bf2b4eadcf379) introduced a change in behaviour for     sh_guest_wrmap, where it had to cope with no shadow     linear mapping being present. As the name suggests,     guest_vtable is a mapping of the guests pagetable, not     Xen's pagetable, meaning that it isn't the pagetable we     need to check for the shadow linear slot in. The     practical upshot is that a shadow HVM vcpu which     switches into 4-level paging mode, with an L4 pagetable     that contains a mapping which aliases Xen's     SH_LINEAR_PT_VIRT_START will fool the safety check for     whether a SHADOW_LINEAR mapping is present. As the check     passes (when it should have failed), Xen subsequently     falls over the missing mapping with a pagefault such as:
    (XEN) Pagetable walk from ffff8140a0503880: (XEN)     L4[0x102] = 000000046c218063 ffffffffffffffff (XEN)     L3[0x102] = 000000046c218063 ffffffffffffffff (XEN)     L2[0x102] = 000000046c218063 ffffffffffffffff (XEN)     L1[0x103] = 0000000000000000 ffffffffffffffff This is     part of XSA-243. (CVE-2017-15592)

The remote OracleVM system is missing necessary patches to address critical security updates :

  - BUILDINFO: OVMF     commit=173bf5c847e3ca8b42c11796ce048d8e2e916ff8

  - BUILDINFO: xen     commit=b90f0a4fa66aea67e743c393ba307612a2fec379

  - BUILDINFO: QEMU upstream     commit=8bff6989bd0bafcc0ddf859c23ce6a2ff21a80ff

  - BUILDINFO: QEMU traditional     commit=346fdd7edd73f8287d0d0a2bab9c67b71bc6b8ba

  - BUILDINFO: IPXE     commit=9a93db3f0947484e30e753bbd61a10b17336e20e

  - BUILDINFO: SeaBIOS     commit=7d9cbe613694924921ed1a6f8947d711c5832eee

  - p2m: Check return value of p2m_set_entry when decreasing     reservation (George Dunlap) [Orabug: 27216264]     (CVE-2017-17045)

  - p2m: Always check to see if removing a p2m entry     actually worked (George Dunlap) [Orabug: 27216264]     (CVE-2017-17045)

  - x86/pod: prevent infinite loop when shattering large     pages (Julien Grall) [Orabug: 27216261] (CVE-2017-17044)

  - xen/physmap: Do not permit a guest to populate PoD pages     for itself (Elena Ufimtseva) [Orabug: 27216261]     (CVE-2017-17044)

  - xend/pxm: Include pxm in XenStore when hotplugging PCI     devices (Konrad Rzeszutek Wilk) [Orabug: 27206706]

  - BUILDINFO: OVMF     commit=173bf5c847e3ca8b42c11796ce048d8e2e916ff8

  - BUILDINFO: xen     commit=2f4972e50ebd2a470b19bfdb1fc6ce91e77614e0

  - BUILDINFO: QEMU upstream     commit=8bff6989bd0bafcc0ddf859c23ce6a2ff21a80ff

  - BUILDINFO: QEMU traditional     commit=346fdd7edd73f8287d0d0a2bab9c67b71bc6b8ba

  - BUILDINFO: IPXE     commit=9a93db3f0947484e30e753bbd61a10b17336e20e

  - BUILDINFO: SeaBIOS     commit=7d9cbe613694924921ed1a6f8947d711c5832eee

  - vNUMA: assign vcpus to nodes by interleaving (Elena     Ufimtseva) 

  - BUILDINFO: OVMF     commit=173bf5c847e3ca8b42c11796ce048d8e2e916ff8

  - BUILDINFO: xen     commit=c9c2df2dc87e18c9dcf584aedf859ab50b62883a

  - BUILDINFO: QEMU upstream     commit=8bff6989bd0bafcc0ddf859c23ce6a2ff21a80ff

  - BUILDINFO: QEMU traditional     commit=346fdd7edd73f8287d0d0a2bab9c67b71bc6b8ba

  - BUILDINFO: IPXE     commit=9a93db3f0947484e30e753bbd61a10b17336e20e

  - BUILDINFO: SeaBIOS     commit=7d9cbe613694924921ed1a6f8947d711c5832eee

  - vNUMA: disable vNUMA if fail to find vcpus for pinning     (Elena Ufimtseva) [Orabug: 27091931]

  - BUILDINFO: OVMF     commit=173bf5c847e3ca8b42c11796ce048d8e2e916ff8

  - BUILDINFO: xen     commit=fe4d54f49f8cf07f9e9d8077b7c85d287fb5c90c

  - BUILDINFO: QEMU upstream     commit=8bff6989bd0bafcc0ddf859c23ce6a2ff21a80ff

  - BUILDINFO: QEMU traditional     commit=346fdd7edd73f8287d0d0a2bab9c67b71bc6b8ba

  - BUILDINFO: IPXE     commit=9a93db3f0947484e30e753bbd61a10b17336e20e

  - BUILDINFO: SeaBIOS     commit=7d9cbe613694924921ed1a6f8947d711c5832eee

  - x86/shadow: correct SH_LINEAR mapping detection in     sh_guess_wrmap (Andrew Cooper) [Orabug: 27148184]     (CVE-2017-15592) (CVE-2017-15592)

  - x86: don't wrongly trigger linear page table assertion     (Jan Beulich) [Orabug: 27148179] (CVE-2017-15595)

  - BUILDINFO: OVMF     commit=173bf5c847e3ca8b42c11796ce048d8e2e916ff8

  - BUILDINFO: xen     commit=b67a2d04c74002cceabfa76612a27fd1cf3f2b29

  - BUILDINFO: QEMU upstream     commit=8bff6989bd0bafcc0ddf859c23ce6a2ff21a80ff

  - BUILDINFO: QEMU traditional     commit=346fdd7edd73f8287d0d0a2bab9c67b71bc6b8ba

  - BUILDINFO: IPXE     commit=9a93db3f0947484e30e753bbd61a10b17336e20e

  - BUILDINFO: SeaBIOS     commit=7d9cbe613694924921ed1a6f8947d711c5832eee

  - vNUMA: fix cpus assignment in manual vNUMA mode. (Elena     Ufimtseva)

The version of Citrix XenServer installed on the remote host is missing a security hotfix. It is, therefore, affected by multiple vulnerabilities as noted in the CTX230138 advisory.

According to its self-reported version number, the Xen hypervisor installed on the remote host is affected by a guest-to-host privilege escalation vulnerability.

This issue only affects HVM guests.

Note that Nessus has checked the changeset versions based on the xen.git change log. Nessus did not check guest hardware configurations or if patches were applied manually to the source code before a recompile and reinstall.

Multiple vulnerabilities have been discovered in the Xen hypervisor, which could result in denial of service, information leaks, privilege escalation or the execution of arbitrary code.

ID	Name	Product	Family	Severity
156595	OracleVM 3.4 : xen (OVMSA-2022-0003)	Nessus	OracleVM Local Security Checks	high
140019	OracleVM 3.4 : xen (OVMSA-2020-0039) (Bunker Buster) (Foreshadow) (MDSUM/RIDL) (MFBDS/RIDL/ZombieLoad) (MLPDS/RIDL) (MSBDS/Fallout) (Meltdown) (POODLE) (Spectre)	Nessus	OracleVM Local Security Checks	critical
118503	Debian DLA-1559-1 : xen security update	Nessus	Debian Local Security Checks	high
111992	OracleVM 3.4 : xen (OVMSA-2018-0248) (Bunker Buster) (Foreshadow) (Meltdown) (POODLE) (Spectre)	Nessus	OracleVM Local Security Checks	critical
106038	GLSA-201801-14 : Xen: Multiple vulnerabilities	Nessus	Gentoo Local Security Checks	high
105869	Fedora 27 : xen (2017-4bfcd57172)	Nessus	Fedora Local Security Checks	high
105717	OracleVM 3.4 : xen (OVMSA-2018-0005) (Meltdown) (Spectre)	Nessus	OracleVM Local Security Checks	high
105621	Debian DLA-1230-1 : xen security update	Nessus	Debian Local Security Checks	high
105511	Fedora 26 : xen (2017-16a414b3c5)	Nessus	Fedora Local Security Checks	high
105251	OracleVM 3.2 : xen (OVMSA-2017-0178)	Nessus	OracleVM Local Security Checks	high
105250	OracleVM 3.3 : xen (OVMSA-2017-0177)	Nessus	OracleVM Local Security Checks	high
105249	OracleVM 3.4 : xen (OVMSA-2017-0176)	Nessus	OracleVM Local Security Checks	high
105083	Citrix XenServer Multiple Vulnerabilities (CTX230138)	Nessus	Misc.	high
104899	Xen Hypervisor Guest-to-Host Privilege Escalation (XSA-247)	Nessus	Misc.	high
104819	Debian DSA-4050-1 : xen - security update	Nessus	Debian Local Security Checks	critical

Detections

Analytics

CVE-2017-17045

high

Tenable Plugins

high

critical

high

critical

high

high

high

high

high

high

high

high

high

high

critical