Your message dated Wed, 08 Jan 2020 16:20:57 +0000 with message-id <[email protected]> and subject line Bug#947944: fixed in xen 4.11.3+24-g14b62ab3e5-1 has caused the Debian Bug report #947944, regarding xen: Several CVEs open for xen (CVE-2018-12207 CVE-2019-11135 CVE-2019-18420 CVE-2019-18421 CVE-2019-18422 CVE-2019-18423 CVE-2019-18424 CVE-2019-18425 CVE-2019-19577 CVE-2019-19578 CVE-2019-19579 CVE-2019-19580 CVE-2019-19581 CVE-2019-19582 CVE-2019-19583) to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 947944: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947944 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---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
--- End Message ---
--- Begin Message ---Source: xen Source-Version: 4.11.3+24-g14b62ab3e5-1 We believe that the bug you reported is fixed in the latest version of xen, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [email protected], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Hans van Kranenburg <[email protected]> (supplier of updated xen package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [email protected]) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 1.8 Date: Wed, 08 Jan 2020 12:41:42 +0100 Source: xen Architecture: source Version: 4.11.3+24-g14b62ab3e5-1 Distribution: unstable Urgency: high Maintainer: Debian Xen Team <[email protected]> Changed-By: Hans van Kranenburg <[email protected]> Closes: 947944 Changes: xen (4.11.3+24-g14b62ab3e5-1) unstable; urgency=high . * Update to new upstream version 4.11.3+24-g14b62ab3e5, which also contains the following security fixes: (Closes: #947944) - Unlimited Arm Atomics Operations XSA-295 CVE-2019-17349 CVE-2019-17350 - VCPUOP_initialise DoS XSA-296 CVE-2019-18420 - missing descriptor table limit checking in x86 PV emulation XSA-298 CVE-2019-18425 - Issues with restartable PV type change operations XSA-299 CVE-2019-18421 - add-to-physmap can be abused to DoS Arm hosts XSA-301 CVE-2019-18423 - passed through PCI devices may corrupt host memory after deassignment XSA-302 CVE-2019-18424 - ARM: Interrupts are unconditionally unmasked in exception handlers XSA-303 CVE-2019-18422 - x86: Machine Check Error on Page Size Change DoS XSA-304 CVE-2018-12207 - TSX Asynchronous Abort speculative side channel XSA-305 CVE-2019-11135 - Device quarantine for alternate pci assignment methods XSA-306 CVE-2019-19579 - find_next_bit() issues XSA-307 CVE-2019-19581 CVE-2019-19582 - VMX: VMentry failure with debug exceptions and blocked states XSA-308 CVE-2019-19583 - Linear pagetable use / entry miscounts XSA-309 CVE-2019-19578 - Further issues with restartable PV type change operations XSA-310 CVE-2019-19580 - Bugs in dynamic height handling for AMD IOMMU pagetables XSA-311 CVE-2019-19577 * Add missing CVE numbers to previous changelog entries Checksums-Sha1: aaafb1b9b82f68a946bfdca0ed03a60c59fc6a3d 4207 xen_4.11.3+24-g14b62ab3e5-1.dsc 0dfed333ead97bfcab82282a89cd152ab1cf4de5 4246660 xen_4.11.3+24-g14b62ab3e5.orig.tar.xz d774863493a5b6987465c678dc73e7ce4292c97e 133852 xen_4.11.3+24-g14b62ab3e5-1.debian.tar.xz Checksums-Sha256: 7e86e40181c387817575a908ae59f5521ad3f277d69ed9948b76c5bf5efbcb60 4207 xen_4.11.3+24-g14b62ab3e5-1.dsc 2286fbfbf986ea4baaae4cad8b3adab3bbd1a966cb019dd3f59a177b8036d189 4246660 xen_4.11.3+24-g14b62ab3e5.orig.tar.xz ccedfe97a1aa92d1e8e96cf367462835d51948b3370b8e461413b312277e33f7 133852 xen_4.11.3+24-g14b62ab3e5-1.debian.tar.xz Files: c852aef3c0ef4a3dd94fda474e9f1d06 4207 admin optional xen_4.11.3+24-g14b62ab3e5-1.dsc 540bbe24beb11abe005a386892b192a5 4246660 admin optional xen_4.11.3+24-g14b62ab3e5.orig.tar.xz e5997186034b940856614606b59da0d4 133852 admin optional xen_4.11.3+24-g14b62ab3e5-1.debian.tar.xz -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEESWyddwNaG9637koYssHfcmNhX2wFAl4V/UwACgkQssHfcmNh X2y0Tw/+PyHRoTaOV4+1KHaDA/B6kN635QvCAvOjEcdUNfPSfTSS4kt7AvHWuH2F WGiDCi8k6gg5Z6XXCVzxr8ptp8Xmhn1LMYEjL6jfkbnSTPC6aKWyZEG41fUgZaIS o5QiwhBAthZIBBm+m9ZtHvdHVXwIzR6Off+a8ONjFVyNQDAjXOGRcWjoguu9GS7l u7W6/zj2nyznT0yC41a2WwRBCtKFSaXl9wJN/9RqtTli7o57V00+cLNsctUaN7SF 2eBksuLWTSLmApU+zvo4+/eWQHozfhp1rfxz+v87OY4SvO1ZbgAw7BWjxUHS/TBf jvV6aOSj7lxZ3xgosSTKVgRPPioNQ41liteouF2tau3ML6PVEuNH6Mp69Qh96JIR /2uA9YydFHC27/2zW9EyucdBcn917kHAQzlRdZ/UWa43xBo/o6hxrnqLif3zmeYw rHffh7sjvLFBj6qrJRj2xot2SojsXXyGCj/8T0FOB5H5/dhHPoY2xArAoxSt28R3 WgzA6Ey7t77rzKpPcQyvujpZUDnuug7OeG4HJ5wuu80paYZ2TxoxNVv00mxBJiCC ChzzfiH5iYTySQClV4iXVwmsq6sBD2zUDHzFkc8quLSGLp7gTreAbFltaXc1v0Vk BtdUuzdxzLMSzLedmUwQH422YCSLq5eGEQJcSecObCZXLt94Lm4= =gGux -----END PGP SIGNATURE-----
--- End Message ---
