Source: xen
Version: 4.11.1+92-g6c33308a8d-2
Severity: grave
Tags: security upstream
Justification: user security hole
Hi,
There are several CVEs open for xen up to unstable, compiling a list
from the information from the security-tracker it looks those below.
Any progress in getting those fixed at least for unstable already?
CVE-2018-12207[0]:
| Improper invalidation for page table updates by a virtual guest
| operating system for multiple Intel(R) Processors may allow an
| authenticated user to potentially enable denial of service of the host
| system via local access.
CVE-2019-11135[1]:
| TSX Asynchronous Abort condition on some CPUs utilizing speculative
| execution may allow an authenticated user to potentially enable
| information disclosure via a side channel with local access.
CVE-2019-18420[2]:
| An issue was discovered in Xen through 4.12.x allowing x86 PV guest OS
| users to cause a denial of service via a VCPUOP_initialise hypercall.
| hypercall_create_continuation() is a variadic function which uses a
| printf-like format string to interpret its parameters. Error handling
| for a bad format character was done using BUG(), which crashes Xen.
| One path, via the VCPUOP_initialise hypercall, has a bad format
| character. The BUG() can be hit if VCPUOP_initialise executes for a
| sufficiently long period of time for a continuation to be created.
| Malicious guests may cause a hypervisor crash, resulting in a Denial
| of Service (DoS). Xen versions 4.6 and newer are vulnerable. Xen
| versions 4.5 and earlier are not vulnerable. Only x86 PV guests can
| exploit the vulnerability. HVM and PVH guests, and guests on ARM
| systems, cannot exploit the vulnerability.
CVE-2019-18421[3]:
| An issue was discovered in Xen through 4.12.x allowing x86 PV guest OS
| users to gain host OS privileges by leveraging race conditions in
| pagetable promotion and demotion operations. There are issues with
| restartable PV type change operations. To avoid using shadow
| pagetables for PV guests, Xen exposes the actual hardware pagetables
| to the guest. In order to prevent the guest from modifying these page
| tables directly, Xen keeps track of how pages are used using a type
| system; pages must be "promoted" before being used as a pagetable, and
| "demoted" before being used for any other type. Xen also allows for
| "recursive" promotions: i.e., an operating system promoting a page to
| an L4 pagetable may end up causing pages to be promoted to L3s, which
| may in turn cause pages to be promoted to L2s, and so on. These
| operations may take an arbitrarily large amount of time, and so must
| be re-startable. Unfortunately, making recursive pagetable promotion
| and demotion operations restartable is incredibly complicated, and the
| code contains several races which, if triggered, can cause Xen to drop
| or retain extra type counts, potentially allowing guests to get write
| access to in-use pagetables. A malicious PV guest administrator may be
| able to escalate their privilege to that of the host. All x86 systems
| with untrusted PV guests are vulnerable. HVM and PVH guests cannot
| exercise this vulnerability.
CVE-2019-18422[4]:
| An issue was discovered in Xen through 4.12.x allowing ARM guest OS
| users to cause a denial of service or gain privileges by leveraging
| the erroneous enabling of interrupts. Interrupts are unconditionally
| unmasked in exception handlers. When an exception occurs on an ARM
| system which is handled without changing processor level, some
| interrupts are unconditionally enabled during exception entry. So
| exceptions which occur when interrupts are masked will effectively
| unmask the interrupts. A malicious guest might contrive to arrange for
| critical Xen code to run with interrupts erroneously enabled. This
| could lead to data corruption, denial of service, or possibly even
| privilege escalation. However a precise attack technique has not been
| identified.
CVE-2019-18423[5]:
| An issue was discovered in Xen through 4.12.x allowing ARM guest OS
| users to cause a denial of service via a XENMEM_add_to_physmap
| hypercall. p2m->max_mapped_gfn is used by the functions
| p2m_resolve_translation_fault() and p2m_get_entry() to sanity check
| guest physical frame. The rest of the code in the two functions will
| assume that there is a valid root table and check that with BUG_ON().
| The function p2m_get_root_pointer() will ignore the unused top bits of
| a guest physical frame. This means that the function p2m_set_entry()
| will alias the frame. However, p2m->max_mapped_gfn will be updated
| using the original frame. It would be possible to set
| p2m->max_mapped_gfn high enough to cover a frame that would lead
| p2m_get_root_pointer() to return NULL in p2m_get_entry() and
| p2m_resolve_translation_fault(). Additionally, the sanity check on
| p2m->max_mapped_gfn is off-by-one allowing "highest mapped + 1" to
| be considered valid. However, p2m_get_root_pointer() will return NULL.
| The problem could be triggered with a specially crafted hypercall
| XENMEM_add_to_physmap{, _batch} followed by an access to an address
| (via hypercall or direct access) that passes the sanity check but
| cause p2m_get_root_pointer() to return NULL. A malicious guest
| administrator may cause a hypervisor crash, resulting in a Denial of
| Service (DoS). Xen version 4.8 and newer are vulnerable. Only Arm
| systems are vulnerable. x86 systems are not affected.
CVE-2019-18424[6]:
| An issue was discovered in Xen through 4.12.x allowing attackers to
| gain host OS privileges via DMA in a situation where an untrusted
| domain has access to a physical device. This occurs because passed
| through PCI devices may corrupt host memory after deassignment. When a
| PCI device is assigned to an untrusted domain, it is possible for that
| domain to program the device to DMA to an arbitrary address. The IOMMU
| is used to protect the host from malicious DMA by making sure that the
| device addresses can only target memory assigned to the guest.
| However, when the guest domain is torn down, or the device is
| deassigned, the device is assigned back to dom0, thus allowing any in-
| flight DMA to potentially target critical host data. An untrusted
| domain with access to a physical device can DMA into host memory,
| leading to privilege escalation. Only systems where guests are given
| direct access to physical devices capable of DMA (PCI pass-through)
| are vulnerable. Systems which do not use PCI pass-through are not
| vulnerable.
CVE-2019-18425[7]:
| An issue was discovered in Xen through 4.12.x allowing 32-bit PV guest
| OS users to gain guest OS privileges by installing and using
| descriptors. There is missing descriptor table limit checking in x86
| PV emulation. When emulating certain PV guest operations, descriptor
| table accesses are performed by the emulating code. Such accesses
| should respect the guest specified limits, unless otherwise guaranteed
| to fail in such a case. Without this, emulation of 32-bit guest user
| mode calls through call gates would allow guest user mode to install
| and then use descriptors of their choice, as long as the guest kernel
| did not itself install an LDT. (Most OSes don't install any LDT by
| default). 32-bit PV guest user mode can elevate its privileges to that
| of the guest kernel. Xen versions from at least 3.2 onwards are
| affected. Only 32-bit PV guest user mode can leverage this
| vulnerability. HVM, PVH, as well as 64-bit PV guests cannot leverage
| this vulnerability. Arm systems are unaffected.
CVE-2019-19577[8]:
| An issue was discovered in Xen through 4.12.x allowing x86 AMD HVM
| guest OS users to cause a denial of service or possibly gain
| privileges by triggering data-structure access during pagetable-height
| updates. When running on AMD systems with an IOMMU, Xen attempted to
| dynamically adapt the number of levels of pagetables (the pagetable
| height) in the IOMMU according to the guest's address space size. The
| code to select and update the height had several bugs. Notably, the
| update was done without taking a lock which is necessary for safe
| operation. A malicious guest administrator can cause Xen to access
| data structures while they are being modified, causing Xen to crash.
| Privilege escalation is thought to be very difficult but cannot be
| ruled out. Additionally, there is a potential memory leak of 4kb per
| guest boot, under memory pressure. Only Xen on AMD CPUs is vulnerable.
| Xen running on Intel CPUs is not vulnerable. ARM systems are not
| vulnerable. Only systems where guests are given direct access to
| physical devices are vulnerable. Systems which do not use PCI pass-
| through are not vulnerable. Only HVM guests can exploit the
| vulnerability. PV and PVH guests cannot. All versions of Xen with
| IOMMU support are vulnerable.
CVE-2019-19578[9]:
| An issue was discovered in Xen through 4.12.x allowing x86 PV guest OS
| users to cause a denial of service via degenerate chains of linear
| pagetables, because of an incorrect fix for CVE-2017-15595. "Linear
| pagetables" is a technique which involves either pointing a pagetable
| at itself, or to another pagetable of the same or higher level. Xen
| has limited support for linear pagetables: A page may either point to
| itself, or point to another pagetable of the same level (i.e., L2 to
| L2, L3 to L3, and so on). XSA-240 introduced an additional restriction
| that limited the "depth" of such chains by allowing pages to either
| *point to* other pages of the same level, or *be pointed to* by other
| pages of the same level, but not both. To implement this, we keep
| track of the number of outstanding times a page points to or is
| pointed to another page table, to prevent both from happening at the
| same time. Unfortunately, the original commit introducing this reset
| this count when resuming validation of a partially-validated
| pagetable, incorrectly dropping some "linear_pt_entry" counts. If an
| attacker could engineer such a situation to occur, they might be able
| to make loops or other arbitrary chains of linear pagetables, as
| described in XSA-240. A malicious or buggy PV guest may cause the
| hypervisor to crash, resulting in Denial of Service (DoS) affecting
| the entire host. Privilege escalation and information leaks cannot be
| excluded. All versions of Xen are vulnerable. Only x86 systems are
| affected. Arm systems are not affected. Only x86 PV guests can
| leverage the vulnerability. x86 HVM and PVH guests cannot leverage the
| vulnerability. Only systems which have enabled linear pagetables are
| vulnerable. Systems which have disabled linear pagetables, either by
| selecting CONFIG_PV_LINEAR_PT=n when building the hypervisor, or
| adding pv-linear-pt=false on the command-line, are not vulnerable.
CVE-2019-19579[10]:
| An issue was discovered in Xen through 4.12.x allowing attackers to
| gain host OS privileges via DMA in a situation where an untrusted
| domain has access to a physical device (and assignable-add is not
| used), because of an incomplete fix for CVE-2019-18424. XSA-302 relies
| on the use of libxl's "assignable-add" feature to prepare devices to
| be assigned to untrusted guests. Unfortunately, this is not considered
| a strictly required step for device assignment. The PCI passthrough
| documentation on the wiki describes alternate ways of preparing
| devices for assignment, and libvirt uses its own ways as well. Hosts
| where these "alternate" methods are used will still leave the system
| in a vulnerable state after the device comes back from a guest. An
| untrusted domain with access to a physical device can DMA into host
| memory, leading to privilege escalation. Only systems where guests are
| given direct access to physical devices capable of DMA (PCI pass-
| through) are vulnerable. Systems which do not use PCI pass-through are
| not vulnerable.
CVE-2019-19580[11]:
| An issue was discovered in Xen through 4.12.x allowing x86 PV guest OS
| users to gain host OS privileges by leveraging race conditions in
| pagetable promotion and demotion operations, because of an incomplete
| fix for CVE-2019-18421. XSA-299 addressed several critical issues in
| restartable PV type change operations. Despite extensive testing and
| auditing, some corner cases were missed. A malicious PV guest
| administrator may be able to escalate their privilege to that of the
| host. All security-supported versions of Xen are vulnerable. Only x86
| systems are affected. Arm systems are not affected. Only x86 PV guests
| can leverage the vulnerability. x86 HVM and PVH guests cannot leverage
| the vulnerability. Note that these attacks require very precise
| timing, which may be difficult to exploit in practice.
CVE-2019-19581[12]:
| An issue was discovered in Xen through 4.12.x allowing 32-bit Arm
| guest OS users to cause a denial of service (out-of-bounds access)
| because certain bit iteration is mishandled. In a number of places
| bitmaps are being used by the hypervisor to track certain state.
| Iteration over all bits involves functions which may misbehave in
| certain corner cases: On 32-bit Arm accesses to bitmaps with bit a
| count which is a multiple of 32, an out of bounds access may occur. A
| malicious guest may cause a hypervisor crash or hang, resulting in a
| Denial of Service (DoS). All versions of Xen are vulnerable. 32-bit
| Arm systems are vulnerable. 64-bit Arm systems are not vulnerable.
CVE-2019-19582[13]:
| An issue was discovered in Xen through 4.12.x allowing x86 guest OS
| users to cause a denial of service (infinite loop) because certain bit
| iteration is mishandled. In a number of places bitmaps are being used
| by the hypervisor to track certain state. Iteration over all bits
| involves functions which may misbehave in certain corner cases: On x86
| accesses to bitmaps with a compile time known size of 64 may incur
| undefined behavior, which may in particular result in infinite loops.
| A malicious guest may cause a hypervisor crash or hang, resulting in a
| Denial of Service (DoS). All versions of Xen are vulnerable. x86
| systems with 64 or more nodes are vulnerable (there might not be any
| such systems that Xen would run on). x86 systems with less than 64
| nodes are not vulnerable.
CVE-2019-19583[14]:
| An issue was discovered in Xen through 4.12.x allowing x86 HVM/PVH
| guest OS users to cause a denial of service (guest OS crash) because
| VMX VMEntry checks mishandle a certain case. Please see XSA-260 for
| background on the MovSS shadow. Please see XSA-156 for background on
| the need for #DB interception. The VMX VMEntry checks do not like the
| exact combination of state which occurs when #DB in intercepted,
| Single Stepping is active, and blocked by STI/MovSS is active, despite
| this being a legitimate state to be in. The resulting VMEntry failure
| is fatal to the guest. HVM/PVH guest userspace code may be able to
| crash the guest, resulting in a guest Denial of Service. All versions
| of Xen are affected. Only systems supporting VMX hardware virtual
| extensions (Intel, Cyrix, or Zhaoxin CPUs) are affected. Arm and AMD
| systems are unaffected. Only HVM/PVH guests are affected. PV guests
| cannot leverage the vulnerability.
If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2018-12207
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12207
[1] https://security-tracker.debian.org/tracker/CVE-2019-11135
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11135
[2] https://security-tracker.debian.org/tracker/CVE-2019-18420
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18420
[3] https://security-tracker.debian.org/tracker/CVE-2019-18421
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18421
[4] https://security-tracker.debian.org/tracker/CVE-2019-18422
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18422
[5] https://security-tracker.debian.org/tracker/CVE-2019-18423
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18423
[6] https://security-tracker.debian.org/tracker/CVE-2019-18424
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18424
[7] https://security-tracker.debian.org/tracker/CVE-2019-18425
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18425
[8] https://security-tracker.debian.org/tracker/CVE-2019-19577
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19577
[9] https://security-tracker.debian.org/tracker/CVE-2019-19578
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19578
[10] https://security-tracker.debian.org/tracker/CVE-2019-19579
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19579
[11] https://security-tracker.debian.org/tracker/CVE-2019-19580
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19580
[12] https://security-tracker.debian.org/tracker/CVE-2019-19581
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19581
[13] https://security-tracker.debian.org/tracker/CVE-2019-19582
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19582
[14] https://security-tracker.debian.org/tracker/CVE-2019-19583
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19583
Please adjust the affected versions in the BTS as needed.
Thanks for your work on the xen packages in Debian.
Regards,
Salvatore
