Xen 4.5.5 + some additional security fixes currently building... I'll fix up cauldron package soon-ish CVE LIST: CVE-2014-3672 CVE-2016-3158 CVE-2016-3159 CVE-2016-3710 CVE-2016-3712 CVE-2016-3960 CVE-2016-4962 CVE-2016-4963 CVE-2016-4480 CVE-2016-5242 CVE-2016-5403 CVE-2016-6258 CVE-2016-6259 CVE-2016-7092 CVE-2016-7093 CVE-2016-7094 CVE-2016-7777 CVE-2016-9377 CVE-2016-9378 CVE-2016-9379 CVE-2016-9380 CVE-2016-9381 CVE-2016-9382 CVE-2016-9383 CVE-2016-9384 CVE-2016-9385 CVE-2016-9386 CVE-2016-9637 SRPMS: xen-4.5.5-1.mga5.src.rpm i586: libxen3.0-4.5.5-1.mga5.i586.rpm libxen-devel-4.5.5-1.mga5.i586.rpm ocaml-xen-4.5.5-1.mga5.i586.rpm ocaml-xen-devel-4.5.5-1.mga5.i586.rpm xen-4.5.5-1.mga5.i586.rpm xen-doc-4.5.5-1.mga5.i586.rpm xen-hypervisor-4.5.5-1.mga5.i586.rpm x86_64: lib64xen3.0-4.5.5-1.mga5.x86_64.rpm lib64xen-devel-4.5.5-1.mga5.x86_64.rpm ocaml-xen-4.5.5-1.mga5.x86_64.rpm ocaml-xen-devel-4.5.5-1.mga5.x86_64.rpm xen-4.5.5-1.mga5.x86_64.rpm xen-doc-4.5.5-1.mga5.x86_64.rpm xen-hypervisor-4.5.5-1.mga5.x86_64.rpm Advisory: This xen update is based on upstream 4.5.5 maintenance release, and fixes the following security issues: The qemu implementation in libvirt before 1.3.0 and Xen allows local guest OS users to cause a denial of service (host disk consumption) by writing to stdout or stderr (CVE-2014-3672) The xrstor function in arch/x86/xstate.c in Xen 4.x does not properly handle writes to the hardware FSW.ES bit when running on AMD64 processors, which allows local guest OS users to obtain sensitive register content information from another guest by leveraging pending exception and mask bits. NOTE: this vulnerability exists because of an incorrect fix for CVE-2013-2076 (CVE-2016-3158). The fpu_fxrstor function in arch/x86/i387.c in Xen 4.x does not properly handle writes to the hardware FSW.ES bit when running on AMD64 processors, which allows local guest OS users to obtain sensitive register content information from another guest by leveraging pending exception and mask bits. NOTE: this vulnerability exists because of an incorrect fix for CVE-2013-2076 (CVE-2016-3159). The VGA module in QEMU improperly performs bounds checking on banked access to video memory, which allows local guest OS administrators to execute arbitrary code on the host by changing access modes after setting the bank register, aka the "Dark Portal" issue (CVE-2016-3710). Integer overflow in the VGA module in QEMU allows local guest OS users to cause a denial of service (out-of-bounds read and QEMU process crash) by editing VGA registers in VBE mode (CVE-2016-3712). Integer overflow in the x86 shadow pagetable code in Xen allows local guest OS users to cause a denial of service (host crash) or possibly gain privileges by shadowing a superpage mapping (CVE-2016-3960). The libxl device-handling in Xen 4.6.x and earlier allows local OS guest administrators to cause a denial of service (resource consumption or management facility confusion) or gain host OS privileges by manipulating information in guest controlled areas of xenstore (CVE-2016-4962). The libxl device-handling in Xen through 4.6.x allows local guest OS users with access to the driver domain to cause a denial of service (management tool confusion) by manipulating information in the backend directories in xenstore (CVE-2016-4963). The guest_walk_tables function in arch/x86/mm/guest_walk.c in Xen 4.6.x and earlier does not properly handle the Page Size (PS) page table entry bit at the L4 and L3 page table levels, which might allow local guest OS users to gain privileges via a crafted mapping of memory (CVE-2016-4480). The p2m_teardown function in arch/arm/p2m.c in Xen 4.4.x through 4.6.x allows local guest OS users with access to the driver domain to cause a denial of service (NULL pointer dereference and host OS crash) by creating concurrent domains and holding references to them, related to VMID exhaustion (CVE-2016-5242). The virtqueue_pop function in hw/virtio/virtio.c in QEMU allows local guest OS administrators to cause a denial of service (memory consumption and QEMU process crash) by submitting requests without waiting for completion (CVE-2016-5403). The PV pagetable code in arch/x86/mm.c in Xen 4.7.x and earlier allows local 32-bit PV guest OS administrators to gain host OS privileges by leveraging fast-paths for updating pagetable entries (CVE-2016-6258). Xen 4.5.x through 4.7.x do not implement Supervisor Mode Access Prevention (SMAP) whitelisting in 32-bit exception and event delivery, which allows local 32-bit PV guest OS kernels to cause a denial of service (hypervisor and VM crash) by triggering a safety check (CVE-2016-6259). The get_page_from_l3e function in arch/x86/mm.c in Xen allows local 32-bit PV guest OS administrators to gain host OS privileges via vectors related to L3 recursive pagetables (CVE-2016-7092). Xen 4.5.3, 4.6.3, and 4.7.x allow local HVM guest OS administrators to overwrite hypervisor memory and consequently gain host OS privileges by leveraging mishandling of instruction pointer truncation during emulation (CVE-2016-7093). Buffer overflow in Xen 4.7.x and earlier allows local x86 HVM guest OS administrators on guests running with shadow paging to cause a denial of service via a pagetable update (CVE-2016-7094). Xen 4.7.x and earlier does not properly honor CR0.TS and CR0.EM, which allows local x86 HVM guest OS users to read or modify FPU, MMX, or XMM register state information belonging to arbitrary tasks on the guest by modifying an instruction while the hypervisor is preparing to emulate it (CVE-2016-7777). When Xen emulates instructions which generate software interrupts it needs to perform a privilege check involving an IDT lookup. This check is sometimes erroneously conducted as if the IDT had the format for a 32-bit guest, when in fact it is in the 64-bit format. Xen will then read the wrong part of the IDT and interpret it in an unintended manner. An unprivileged guest user program may be able to crash the guest (CVE-2016-9377). When Xen emulates instructions which generate software interrupts, and chooses to deliver the software interrupt, it may try to use the method intended for injecting exceptions. This is incorrect, and results in a guest crash (CVE-2016-9378). pygrub supports a number of output formats. When the S-expression output format is requested, putting string quotes and S-expressions in the bootloader configuration file can produce incorrect output. A malicious guest administrator can obtain the contents of sensitive host files (an information leak), or can cause files on the host to be removed, causing a denial of service or in unusual cases privilegie escalation (CVE-2016-9379). When the nul-delimited output format is requested, nul bytes in the bootloader configuration file can produce an ambiguous or confusing output file, which is interpreted by libxl in a vulnerable way. A malicious guest administrator can obtain the contents of sensitive host files (an information leak), or can cause files on the host to be removed, causing a denial of service or in unusual cases privilegie escalation (CVE-2016-9380). The compiler can emit optimizations in qemu which can lead to double fetch vulnerabilities. Specifically data on the rings shared between qemu and the hypervisor (which the guest under control can obtain mappings of) can be fetched twice (during which time the guest can alter the contents) possibly leading to arbitrary code execution in qemu. Malicious administrators can exploit this vulnerability to take over the qemu process, elevating its privilege to that of the qemu process. In a system not using a device model stub domain (or other techniques for deprivileging qemu), malicious guest administrators can thus elevate their privilege to that of the host (CVE-2016-9381). LDTR, just like TR, is purely a protected mode facility. Hence even when switching to a VM86 mode task, LDTR loading needs to follow protected mode semantics. This was violated by the code. On SVM (AMD hardware): a malicious unprivileged guest process can escalate its privilege to that of the guest operating system. On both SVM and VMX (Intel hardware): a malicious unprivileged guest process can crash the guest (CVE-2016-9382). The x86 instructions BT, BTC, BTR, and BTS, when used with a destination memory operand and a source register rather than an immediate operand, access a memory location offset from that specified by the memory operand as specified by the high bits of the register source. When Xen needs to emulate such an instruction, to efficiently handle the emulation, the memory address and register operand are recalculated internally to Xen. In this process, the high bits of an intermediate expression were discarded, leading to both the memory location and the register operand being wrong. A malicious guest can modify arbitrary memory, allowing for arbitrary code execution (and therefore privilege escalation affecting the whole host), a crash of the host (leading to a DoS), or information leaks (CVE-2016-9383). Along with their main kernel binary, unprivileged guests may arrange to have their Xen environment load (kernel) symbol tables for their use. The ELF image metadata created for this purpose has a few unused bytes when the symbol table binary is in 32-bit ELF format. These unused bytes were not properly cleared during symbol table loading. A malicious unprivileged guest may be able to obtain sensitive information from the host (CVE-2016-9384). Both writes to the FS and GS register base MSRs as well as the WRFSBASE and WRGSBASE instructions require their input values to be canonical, or a #GP fault will be raised. When the use of those instructions by the hypervisor was enabled, the previous guard against #GP faults (having recovery code attached) was accidentally removed. A malicious guest administrator can crash the host, leading to a DoS (CVE-2016-9385). The Xen x86 emulator erroneously failed to consider the unusability of segments when performing memory accesses. An unprivileged guest user program may be able to elevate its privilege to that of the guest operating system (CVE-2016-9386). The code in qemu which implements ioport read/write looks up the specified ioport address in a 32-bit dispatch table without proper range checks. Xen will write only 16-bit address ioport accesses. However, depending on the Xen and qemu version, the ring may be writeable by the guest. If so, the guest can generate out-of-range ioport accesses, resulting in wild pointer accesses within qemu. A malicious guest administrator can escalate their privilege to that of the host (CVE-2016-9637). For other fixes in this update, see the referenced changelogs. References: https://www.xenproject.org/downloads/xen-archives/xen-45-series/xen-453.html https://www.xenproject.org/downloads/xen-archives/xen-45-series/xen-455.html https://xenbits.xen.org/xsa/advisory-172.html https://xenbits.xen.org/xsa/advisory-173.html https://xenbits.xen.org/xsa/advisory-175.html https://xenbits.xen.org/xsa/advisory-176.html https://xenbits.xen.org/xsa/advisory-178.html https://xenbits.xen.org/xsa/advisory-179.html https://xenbits.xen.org/xsa/advisory-180.html https://xenbits.xen.org/xsa/advisory-181.html https://xenbits.xen.org/xsa/advisory-182.html https://xenbits.xen.org/xsa/advisory-183.html https://xenbits.xen.org/xsa/advisory-184.html https://xenbits.xen.org/xsa/advisory-185.html https://xenbits.xen.org/xsa/advisory-186.html https://xenbits.xen.org/xsa/advisory-187.html https://xenbits.xen.org/xsa/advisory-190.html https://xenbits.xen.org/xsa/advisory-191.html https://xenbits.xen.org/xsa/advisory-192.html https://xenbits.xen.org/xsa/advisory-193.html https://xenbits.xen.org/xsa/advisory-194.html https://xenbits.xen.org/xsa/advisory-195.html https://xenbits.xen.org/xsa/advisory-196.html https://xenbits.xen.org/xsa/advisory-197.html https://xenbits.xen.org/xsa/advisory-198.html https://xenbits.xen.org/xsa/advisory-199.html
CC: (none) => davidwhodginsWhiteboard: (none) => advisory
Interesting while installing x86_64 it also set the Kernel server 3.19.8.3 as well as 4.4.36.2 server. Why? I will continue forward.
CC: (none) => brtians1
following process I used in https://bugs.mageia.org/show_bug.cgi?id=16956. Except new kernel reference. I'm running grub, will need to update for grub2.
okay - I didn't like 3.19 running, so set up my grub - /boot/grub/menu.lst with this entry at the bottom. title xen_server kernel (hd0,4)/boot/xen.gz dom0_mem=4084M,max:6096M loglvl=all guest_loglvl=all module (hd0,4)/boot/vmlinuz-4.4.36-server-2.mga5 BOOT_IMAGE=server_4.4.36-2.mga5 root=UUID=55e55dd4-5dfd-4eb4-ada5-79a63f006878 splash quiet noiswmd resume=UUID=24b4cd5a-0a6e-41a5-b02e-087f372f1783 vga=788 root (hd0,4) module (hd0,4)/boot/initrd.img rebooted and picked that option # uname -a Linux localhost 4.4.36-server-2.mga5 #1 SMP Tue Dec 6 17:32:56 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux # ps -ef | grep xen root 21 2 0 16:30 ? 00:00:00 [xenwatch] root 22 2 0 16:30 ? 00:00:00 [xenbus] root 30 2 0 16:30 ? 00:00:00 [xenbus_frontend] root 491 2 0 16:30 ? 00:00:00 [xen_pciback_wor] root 948 1 0 16:30 ? 00:00:00 /usr/sbin/oxenstored --no-fork root 1002 1 0 16:30 ? 00:00:00 /usr/sbin/xenconsoled --pid-file /var/run/xen/xenconsoled.pid --log=none --log-dir=/var/log/xen/console root 1144 1 0 16:30 ? 00:00:00 /usr/libexec/xen/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null -serial /dev/null -parallel /dev/null -pidfile /var/run/xen/qemu-dom0.pid Hurray it is running. will try set up VM's now.
I installed virt-manager and qemu. Was able to run puppy linux as a VM Works for me.
Whiteboard: advisory => advisory MGA5-64-OK
taking away the validated-ok because it did pull in an old kernel as part of the install. Let me know.
Whiteboard: advisory MGA5-64-OK => advisory
Whiteboard: advisory => advisory feedback
Changed the server deps and fixed 3 more security issues: - x86 CMPXCHG8B emulation fails to ignore operand size override. A malicious unprivileged guest may be able to obtain sensitive information from the host (CVE-2016-9932). - x86 PV guests may be able to mask interrupts. A malicious guest kernel administrator can cause a host hang or crash, resulting in a Denial of Service (CVE-2016-10024). - x86: Mishandling of SYSCALL singlestep during emulation. Guest userspace which can invoke the instruction emulator can use this flaw to escalate its privilege to that of the guest kernel (CVE-2016-10013). (advisory in svn updated) new rpms to test: SRPMS: xen-4.5.5-1.1.mga5.src.rpm i586: libxen3.0-4.5.5-1.1.mga5.i586.rpm libxen-devel-4.5.5-1.1.mga5.i586.rpm ocaml-xen-4.5.5-1.1.mga5.i586.rpm ocaml-xen-devel-4.5.5-1.1.mga5.i586.rpm xen-4.5.5-1.1.mga5.i586.rpm xen-doc-4.5.5-1.1.mga5.i586.rpm xen-hypervisor-4.5.5-1.1.mga5.i586.rpm x86_64: lib64xen3.0-4.5.5-1.1.mga5.x86_64.rpm lib64xen-devel-4.5.5-1.1.mga5.x86_64.rpm ocaml-xen-4.5.5-1.1.mga5.x86_64.rpm ocaml-xen-devel-4.5.5-1.1.mga5.x86_64.rpm xen-4.5.5-1.1.mga5.x86_64.rpm xen-doc-4.5.5-1.1.mga5.x86_64.rpm xen-hypervisor-4.5.5-1.1.mga5.x86_64.rpm
Whiteboard: advisory feedback => advisory
The following 38 packages are going to be installed: - cyrus-sasl-2.1.26-10.mga5.x86_64 - glibc-devel-2.20-23.mga5.x86_64 - kernel-server-4.4.39-1.mga5-1-1.mga5.x86_64 - kernel-server-latest-4.4.39-1.mga5.x86_64 - kernel-userspace-headers-4.4.39-1.mga5.x86_64 - lib64aio1-0.3.110-3.mga5.x86_64 - lib64brlapi0.6-4.5-16.mga5.x86_64 - lib64bzip2-devel-1.0.6-7.1.mga5.x86_64 - lib64celt051_0-0.5.1.3-9.mga5.x86_64 - lib64gcrypt-devel-1.5.4-5.3.mga5.x86_64 - lib64gpg-error-devel-1.13-3.mga5.x86_64 - lib64lzma-devel-5.2.0-1.mga5.x86_64 - lib64nl-cli3_200-3.2.25-3.mga5.x86_64 - lib64nl-nf3_200-3.2.25-3.mga5.x86_64 - lib64nl-route3_200-3.2.25-3.mga5.x86_64 - lib64nl3-devel-3.2.25-3.mga5.x86_64 - lib64ossp_uuid-devel-1.6.2-12.mga5.x86_64 - lib64ossp_uuid16-1.6.2-12.mga5.x86_64 - lib64sasl2-plug-anonymous-2.1.26-10.mga5.x86_64 - lib64sasl2-plug-login-2.1.26-10.mga5.x86_64 - lib64sasl2-plug-plain-2.1.26-10.mga5.x86_64 - lib64spice-server1-0.12.5-2.3.mga5.x86_64 - lib64usbredirparser1-0.7-3.mga5.x86_64 - lib64vde3-2.3.2-11.mga5.x86_64 - lib64xen-devel-4.5.5-1.1.mga5.x86_64 - lib64xen3.0-4.5.5-1.1.mga5.x86_64 - lib64yajl-devel-2.0.4-5.mga5.x86_64 - lib64yajl2-2.0.4-5.mga5.x86_64 - lib64zlib-devel-1.2.8-7.1.mga5.x86_64 - ocaml-compiler-4.01.0-11.mga5.x86_64 - ocaml-xen-4.5.5-1.1.mga5.x86_64 - ocaml-xen-devel-4.5.5-1.1.mga5.x86_64 - qemu-2.4.1-7.mga5.x86_64 - qemu-img-2.4.1-7.mga5.x86_64 - systemd-devel-217-11.2.mga5.x86_64 - xen-4.5.5-1.1.mga5.x86_64 - xen-doc-4.5.5-1.1.mga5.x86_64 - xen-hypervisor-4.5.5-1.1.mga5.x86_64 304MB of additional disk space will be used. 96MB of packages will be retrieved. Is it ok to continue? title xen_server kernel (hd0,4)/boot/xen.gz dom0_mem=4084M,max:6096M loglvl=all guest_loglvl=all module (hd0,4)/boot/vmlinuz-4.4.39-server-1.mga5 BOOT_IMAGE=server_4.4.39-1.mga5 root=UUID=55e55dd4-5dfd-4eb4-ada5-79a63f006878 splash quiet noiswmd resume=UUID=24b4cd5a-0a6e-41a5-b02e-087f372f1783 vga=788 root (hd0,4) module (hd0,4)/boot/initrd.img rebooted â chose xen_server option at terminal [brian@localhost ~]$ ps -ef | grep xen root 21 2 0 10:23 ? 00:00:00 [xenwatch] root 22 2 0 10:23 ? 00:00:00 [xenbus] root 30 2 0 10:23 ? 00:00:00 [xenbus_frontend] root 504 2 0 10:23 ? 00:00:00 [xen_pciback_wor] root 762 1 0 10:23 ? 00:00:00 /usr/sbin/oxenstored --no-fork root 863 1 0 10:23 ? 00:00:00 /usr/sbin/xenconsoled --pid-file /var/run/xen/xenconsoled.pid --log=none --log-dir=/var/log/xen/console root 973 1 0 10:23 ? 00:00:00 /usr/libexec/xen/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null -serial /dev/null -parallel /dev/null -pidfile /var/run/xen/qemu-dom0.pid hurray â it's running. Installing virt-manager To satisfy dependencies, the following package(s) also need to be installed: - gtk-vnc-i18n-0.5.3-6.mga5.noarch - lib64cacard0-0.1.2-5.mga5.x86_64 - lib64gtk-vnc2.0_0-0.5.3-6.mga5.x86_64 - lib64gtkvnc-gir2.0-0.5.3-6.mga5.x86_64 - lib64gvnc-gir1.0-0.5.3-6.mga5.x86_64 - lib64gvnc1.0_0-0.5.3-6.mga5.x86_64 - lib64osinfo-gir1.0-0.2.11-5.mga5.x86_64 - lib64osinfo1.0_0-0.2.11-5.mga5.x86_64 - lib64spice-client-glib-gir2.0-0.25-5.mga5.x86_64 - lib64spice-client-glib2.0_8-0.25-5.mga5.x86_64 - lib64spice-client-gtk-gir3.0-0.25-5.mga5.x86_64 - lib64spice-client-gtk3.0_4-0.25-5.mga5.x86_64 - lib64usbredirhost1-0.7-3.mga5.x86_64 - lib64virt-glib-gir1.0-0.1.9-5.mga5.x86_64 - lib64virt-glib1.0_0-0.1.9-5.mga5.x86_64 - lib64virt0-1.2.9.3-1.4.mga5.x86_64 - lib64vte-gir2.91-0.38.3-1.mga5.x86_64 - lib64vte2.91_0-0.38.3-1.mga5.x86_64 - lib64xml2-gir2.0-1.42.0-3.mga5.x86_64 - libcacard-tools-0.1.2-5.mga5.x86_64 - libosinfo-common-0.2.11-5.mga5.x86_64 - python-curl-7.19.5-4.1.mga5.x86_64 - python-ipaddr-2.1.10-7.mga5.noarch - python-libvirt-1.2.9-2.mga5.x86_64 - python-urlgrabber-3.10.1-5.mga5.noarch - spice-gtk-0.25-5.mga5.x86_64 - vte3-0.38.3-1.mga5.x86_64 - vte3-profile-0.38.3-1.mga5.noarch 19MB of additional disk space will be used. Had to add the following as well The following 10 packages are going to be installed: - augeas-lenses-1.2.0-3.mga5.x86_64 - dnsmasq-2.71-4.mga5.x86_64 - dnsmasq-base-2.71-4.mga5.x86_64 - ebtables-2.0.10.4-6.mga5.x86_64 - lib64augeas0-1.2.0-3.mga5.x86_64 - lib64fa1-1.2.0-3.mga5.x86_64 - lib64netcf1-0.2.8-1.mga5.x86_64 - libvirt-utils-1.2.9.3-1.4.mga5.x86_64 - netcat-openbsd-1.89-8.mga5.x86_64 - netcf-0.2.8-1.mga5.x86_64 39MB of additional disk space will be used. Rebooted to bring in the services I was able to spin up puppy linux in a VM.
Thank you Brian for your perseverence with Xen. Looking at Bug 16956 that you referenced, that was let out with just a 64-bit OK. So validating this; advisory already in place for xen-4.5.5-1.1.mga5.src.rpm
Keywords: (none) => validated_updateCC: (none) => lewyssmith, sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2017-0012.html
Status: NEW => RESOLVEDResolution: (none) => FIXED