Security update for xen

Open Source Vulnerabilities SUSE-SU-2018:2528-1

This update for xen fixes the following issues: These security issue were fixed: - CVE-2018-3646: Systems with microprocessors utilizing speculative execution and address translations may have allowed unauthorized disclosure of information residing in the L1 data cache to an attacker with local user access with guest OS privilege via a terminal page fault and a side-channel analysis (bsc#1091107, bsc#1027519). - CVE-2018-12617: An integer overflow that could cause a segmentation fault in qmp_guest_file_read() with g_malloc() in qemu-guest-agent was fixed (bsc#1098744) - CVE-2018-3665: System software utilizing Lazy FP state restore technique on systems using Intel Core-based microprocessors may potentially allow a local process to infer data from another process through a speculative execution side channel. (bsc#1095242) - CVE-2018-3639: Systems with microprocessors utilizing speculative execution and speculative execution of memory reads before the addresses of all prior memory writes are known may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis, aka Speculative Store Bypass (SSB), Variant 4. (bsc#1092631) - CVE-2017-5715: Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis. (bsc#1074562) - CVE-2017-5753: Systems with microprocessors utilizing speculative execution and branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis. (bsc#1074562) - CVE-2017-5754: Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis of the data cache. (bsc#1074562) - CVE-2018-12891: Certain PV MMU operations may take a long time to process. For that reason Xen explicitly checks for the need to preempt the current vCPU at certain points. A few rarely taken code paths did bypass such checks. By suitably enforcing the conditions through its own page table contents, a malicious guest may cause such bypasses to be used for an unbounded number of iterations. A malicious or buggy PV guest may cause a Denial of Service (DoS) affecting the entire host. Specifically, it may prevent use of a physical CPU for an indeterminate period of time. (bsc#1097521) - CVE-2018-12893: One of the fixes in XSA-260 added some safety checks to help prevent Xen livelocking with debug exceptions. Unfortunately, due to an oversight, at least one of these safety checks can be triggered by a guest. A malicious PV guest can crash Xen, leading to a Denial of Service. Only x86 PV guests can exploit the vulnerability. x86 HVM and PVH guests cannot exploit the vulnerability. An attacker needs to be able to control hardware debugging facilities to exploit the vulnerability, but such permissions are typically available to unprivileged users. (bsc#1097522) - CVE-2018-11806: m_cat in slirp/mbuf.c in Qemu has a heap-based buffer overflow via incoming fragmented datagrams. (bsc#1096224) - CVE-2018-10982: An issue was discovered in Xen allowed x86 HVM guest OS users to cause a denial of service (unexpectedly high interrupt number, array overrun, and hypervisor crash) or possibly gain hypervisor privileges by setting up an HPET timer to deliver interrupts in IO-APIC mode, aka vHPET interrupt injection. (bsc#1090822) - CVE-2018-10981: An issue was discovered in Xen that allowed x86 HVM guest OS users to cause a denial of service (host OS infinite loop) in situations where a QEMU device model attempts to make invalid transitions between states of a request. (bsc#1090823) Following bugs were fixed: - After updating to kernel 3.0.101-0.47.106.32-xen system crashes in check_bugs() (bsc#1097206) - bsc#1079730 - in xen-kmp, unplug emulated devices after migration This is required since xen-4.10 and/or qemu-2.10 because the state of unplug is not propagated from one dom0 to another. Without this unplug qemu's block-backend will be unable to open qcow2 disks on the receiving dom0