fixes for now in 4.5.1-1.mga5/6 currently pushed to mga5 testing and cauldron: - update to 4.5.1 fixes XSA-117 to XSA-136 - add missing xsa135 fixes to qemu-xen-traditional - add fixes for xsa137-xsa142 - fix ixpe ath9k build with gcc 5.1+ XSA-14[5-7] gets published 2015-10-29, will wait for them before pushing to QA to save some qa work Reproducible: Steps to Reproduce:
Adding Alien in cc as he's official maintainer
Whiteboard: (none) => MGA5TOOCC: (none) => alien
(In reply to Thomas Backlund from comment #0) > XSA-14[5-7] gets published 2015-10-29, will wait for them before pushing to > QA to save some qa work Just got XSA-148, also to be published on 2015-10-29.
CC: (none) => luigiwalser
Assigning this to QA for some "initial testing"... there will be more security fixes getting public in a few weeks... so there will be a rebuild, but since this has not been tested lately, it may take some time... I will write up an advisory later... security fixes so far: CVE-2015-0268 CVE-2015-1563 CVE-2015-2044 CVE-2015-2045 CVE-2015-2150 CVE-2015-2151 CVE-2015-2152 CVE-2015-2751 CVE-2015-2752 CVE-2015-2756 CVE-2015-3209 CVE-2015-3259 CVE-2015-3340 CVE-2015-3456 CVE-2015-4103 CVE-2015-4104 CVE-2015-4105 CVE-2015-4106 CVE-2015-4163 CVE-2015-4164 CVE-2015-5154 CVE-2015-5165 CVE-2015-5166 CVE-2015-6654 CVE-2015-7311 SRPM: xen-4.5.1-1.mga5.src.rpm i586: libxen3.0-4.5.1-1.mga5.i586.rpm libxen-devel-4.5.1-1.mga5.i586.rpm ocaml-xen-4.5.1-1.mga5.i586.rpm ocaml-xen-devel-4.5.1-1.mga5.i586.rpm xen-4.5.1-1.mga5.i586.rpm xen-doc-4.5.1-1.mga5.i586.rpm xen-hypervisor-4.5.1-1.mga5.i586.rpm x86_64: lib64xen3.0-4.5.1-1.mga5.x86_64.rpm lib64xen-devel-4.5.1-1.mga5.x86_64.rpm ocaml-xen-4.5.1-1.mga5.x86_64.rpm ocaml-xen-devel-4.5.1-1.mga5.x86_64.rpm xen-4.5.1-1.mga5.x86_64.rpm xen-doc-4.5.1-1.mga5.x86_64.rpm xen-hypervisor-4.5.1-1.mga5.x86_64.rpm
Assignee: tmb => qa-bugs
Comment 0 is private: 1 => 0 Comment 3 is private: 1 => 0
Created attachment 7126 [details] Notes from previous test of xen
CC: (none) => davidwhodgins
i wanted to note that i was working on a 4.5.1 build that had qemu removed and link to upstream qemu instead... however, i had some issues regarding pv that seemed broken with qemu removed... (perhaps i removed too much). i guess this will be for cauldron only, allthough i had thought if putting this on mga5 too... (it would remove the qemu traditional and the bundled one too)
(In reply to AL13N from comment #6) > i wanted to note that i was working on a 4.5.1 build that had qemu removed > and link to upstream qemu instead... > Hm, yeah, well I did not see any movement in since ~ February and with the security issues piling up... > however, i had some issues regarding pv that seemed broken with qemu > removed... (perhaps i removed too much). > > i guess this will be for cauldron only, allthough i had thought if putting > this on mga5 too... Yeah, I think it's safer to do this as cauldron only for now... and you could rebase xen to 4.6 in cauldron
Version: Cauldron => 5Whiteboard: MGA5TOO => (none)
As usual, having some problems. Have xen running on the host. Trying to create a hvm guest using the command "xl create hvmtest -c -d -V" and the config file ... builder="hvm" name="hvmtest" vcpus=2 memory=512 maxmem=4096 disk = [ 'file:/opt/hvmtest.img,sda,w', 'file:/b3/m4/Mageia-5-netinstall-x86_64-CD/boot-nonfree.iso,hdb:cdrom,r', ] vif = [ 'type=ioemu mac=00:14:51:71:ae:47, bridge=xenbr', ] boot="dc" The guest starts, but as soon as the installer starts the scan for usb devices, the guest terminates. I'll append xenstored-access.log
Created attachment 7164 [details] xenstored-access.log
Please see comments 8 and 9. It there anything that needs to be changed for usb access within the guest? Thomas, go ahead and validate anyway?
Whiteboard: (none) => feedback
Actually the current build was only meant for pre-testing, not final validation. Additional security issues were made public today, which Thomas will include patches for sometime soon.
Ok, ready for tests: SRPMS: xen-4.5.1-1.1.mga5.src.rpm i586: libxen3.0-4.5.1-1.1.mga5.i586.rpm libxen-devel-4.5.1-1.1.mga5.i586.rpm ocaml-xen-4.5.1-1.1.mga5.i586.rpm ocaml-xen-devel-4.5.1-1.1.mga5.i586.rpm xen-4.5.1-1.1.mga5.i586.rpm xen-doc-4.5.1-1.1.mga5.i586.rpm xen-hypervisor-4.5.1-1.1.mga5.i586.rpm x86_64: lib64xen3.0-4.5.1-1.1.mga5.x86_64.rpm lib64xen-devel-4.5.1-1.1.mga5.x86_64.rpm ocaml-xen-4.5.1-1.1.mga5.x86_64.rpm ocaml-xen-devel-4.5.1-1.1.mga5.x86_64.rpm xen-4.5.1-1.1.mga5.x86_64.rpm xen-doc-4.5.1-1.1.mga5.x86_64.rpm xen-hypervisor-4.5.1-1.1.mga5.x86_64.rpm Full CVE list: CVE-2015-0268 CVE-2015-1563 CVE-2015-2044 CVE-2015-2045 CVE-2015-2150 CVE-2015-2151 CVE-2015-2152 CVE-2015-2751 CVE-2015-2752 CVE-2015-2756 CVE-2015-3209 CVE-2015-3259 CVE-2015-3340 CVE-2015-3456 CVE-2015-4103 CVE-2015-4104 CVE-2015-4105 CVE-2015-4106 CVE-2015-4163 CVE-2015-4164 CVE-2015-5154 CVE-2015-5165 CVE-2015-5166 CVE-2015-6654 CVE-2015-7311 CVE-2015-7812 CVE-2015-7813 CVE-2015-7814 CVE-2015-7835 CVE-2015-7969 CVE-2015-7970 CVE-2015-7971 CVE-2015-7972 Advisory: This xen update is based on upstream 4.5.1, and fixes the following security issues: The vgic_v2_to_sgi function in arch/arm/vgic-v2.c in Xen 4.5.x, when running on ARM hardware with general interrupt controller (GIC) version 2, allows local guest users to cause a denial of service (host crash) by writing an invalid value to the GICD.SGIR register (CVE-2015-0268). The ARM GIC distributor virtualization in Xen 4.4.x and 4.5.x allows local guests to cause a denial of service by causing a large number messages to be logged (CVE-2015-1563). The emulation routines for unspecified X86 devices in Xen 3.2.x through 4.5.x does not properly initialize data, which allow local HVM guest users to obtain sensitive information via vectors involving an unsupported access size (CVE-2015-2044). The HYPERVISOR_xen_version hypercall in Xen 3.2.x through 4.5.x does not properly initialize data structures, which allows local guest users to obtain sensitive information via unspecified vectors (CVE-2015-2045). Xen 3.3.x through 4.5.x and the Linux kernel through 3.19.1 do not properly restrict access to PCI command registers, which might allow local guest users to cause a denial of service (non-maskable interrupt and host crash) by disabling the (1) memory or (2) I/O decoding for a PCI Express device and then accessing the device, which triggers an Unsupported Request (UR) response (CVE-2015-2150). The x86 emulator in Xen 3.2.x through 4.5.x does not properly ignore segment overrides for instructions with register operands, which allows local guest users to obtain sensitive information, cause a denial of service (memory corruption), or possibly execute arbitrary code via unspecified vectors (CVE-2015-2151). Xen 4.5.x and earlier enables certain default backends when emulating a VGA device for an x86 HVM guest qemu even when the configuration disables them, which allows local guest users to obtain access to the VGA console by (1) setting the DISPLAY environment variable, when compiled with SDL support, or connecting to the VNC server on (2) ::1 or (3) 127.0.0.1, when not compiled with SDL support (CVE-2015-2152). Xen 4.3.x, 4.4.x, and 4.5.x, when using toolstack disaggregation, allows remote domains with partial management control to cause a denial of service (host lock) via unspecified domctl operations (CVE-2015-2751). The XEN_DOMCTL_memory_mapping hypercall in Xen 3.2.x through 4.5.x, when using a PCI passthrough device, is not preemptable, which allows local x86 HVM domain users to cause a denial of service (host CPU consumption) via a crafted request to the device model (qemu-dm) (CVE-2015-2752). QEMU, as used in Xen 3.3.x through 4.5.x, does not properly restrict access to PCI command registers, which might allow local HVM guest users to cause a denial of service (non-maskable interrupt and host crash) by disabling the (1) memory or (2) I/O decoding for a PCI Express device and then accessing the device, which triggers an Unsupported Request (UR) response (CVE-2015-2756). Heap-based buffer overflow in the PCNET controller in QEMU allows remote attackers to execute arbitrary code by sending a packet with TXSTATUS_STARTPACKET set and then a crafted packet with TXSTATUS_DEVICEOWNS set (CVE-2015-3209). Stack-based buffer overflow in the xl command line utility in Xen 4.1.x through 4.5.x allows local guest administrators to gain privileges via a long configuration argument (CVE-2015-3259). Xen 4.2.x through 4.5.x does not initialize certain fields, which allows certain remote service domains to obtain sensitive information from memory via a (1) XEN_DOMCTL_gettscinfo or (2) XEN_SYSCTL_getdomaininfolist request (CVE-2015-3340). The Floppy Disk Controller (FDC) in QEMU, as used in Xen 4.5.x and earlier and KVM, allows local guest users to cause a denial of service (out-of-bounds write and guest crash) or possibly execute arbitrary code via the (1) FD_CMD_READ_ID, (2) FD_CMD_DRIVE_SPECIFICATION_COMMAND, or other unspecified commands, aka VENOM (CVE-2015-3456). Xen 3.3.x through 4.5.x does not properly restrict write access to the host MSI message data field, which allows local x86 HVM guest administrators cause a denial of service (host interrupt handling confusion) via vectors related to qemu and accessing spanning multiple fields (CVE-2015-4103). Xen 3.3.x through 4.5.x does not properly restrict access to PCI MSI mask bits, which allows local x86 HVM guest users to cause a denial of service (unexpected interrupt and host crash) via unspecified vectors (CVE-2015-4104). Xen 3.3.x through 4.5.x enables logging for PCI MSI-X pass-through error messages, which allows local x86 HVM guests to cause a denial of service (host disk consumption) via certain invalid operations (CVE-2015-4105). QEMU does not properly restrict write access to the PCI config space for certain PCI pass-through devices, which mighy allow local x86 HVM guests to gain privileges, cause a denial of service (host crash), obtain sensitive information, or possibly have other unspecified impact via unknown vectors (CVE-2015-4106). GNTTABOP_swap_grant_ref in Xen 4.2 through 4.5 does not check the grant table operation version, which allows local guest domains to cause a denial of service (NULL pointer dereference) via a hypercall without a GNTTABOP_setup_table or GNTTABOP_set_version (CVE-2015-4163). The compat_iret function in Xen 3.1 through 4.5 iterates the wrong way through a loop, which allows local 32-bit PV guest administrators to cause a denial of service (large loop and system hang) via a hypercall_iret call with EFLAGS.VM set (CVE-2015-4164). Heap-based buffer overflow in the IDE subsystem in QEMU, as used in Xen 4.5.x and earlier, when the container has a CDROM drive enabled, allows local guest users to execute arbitrary code on the host via unspecified ATAPI commands (CVE-2015-5154). The C+ mode offload emulation in the RTL8139 network card device model in QEMU, as used in Xen 4.5.x and earlier, allows remote attackers to read process heap memory via unspecified vectors (CVE-2015-5165). Use-after-free vulnerability in QEMU in Xen 4.5.x and earlier does not completely unplug emulated block devices, which allows local HVM guest users to gain privileges by unplugging a block device twice (CVE-2015-5166). The xenmem_add_to_physmap_one function in arch/arm/mm.c in Xen 4.5.x, 4.4.x, and earlier does not limit the number of printk console messages when reporting a failure to retrieve a reference on a foreign page, which allows remote domains to cause a denial of service by leveraging permissions to map the memory of a foreign guest (CVE-2015-6654). libxl in Xen 4.1.x through 4.6.x does not properly handle the readonly flag on disks when using the qemu-xen device model, which allows local guest users to write to a read-only disk image (CVE-2015-7311). Multicall support for arm in xen 4.4.x and later was not correctly set up with correct functionality and therefore exposed to guests a code path which crashes the host. Any guest can issue a preemptable hypercall via the multicall interface to exploit this vulnerability (CVE-2015-7812). Xen 4.4.x, 4.5.x, and 4.6.x does not limit the number of printk console messages when reporting unimplemented hypercalls, which allows local guests to cause a denial of service via a sequence of (1) HYPERVISOR_physdev_op hypercalls, which are not properly handled in the do_physdev_op function in arch/arm/physdev.c, or (2) HYPERVISOR_hvm_op hypercalls, which are not properly handled in the do_hvm_op function in arch/arm/hvm.c (CVE-2015-7813). Race condition in the relinquish_memory function in arch/arm/domain.c in Xen 4.6.x and earlier allows local domains with partial management control to cause a denial of service (host crash) via vectors involving the destruction of a domain and using XENMEM_decrease_reservation to reduce the memory of the domain (CVE-2015-7814). The mod_l2_entry function in arch/x86/mm.c in Xen 3.4 through 4.6.x does not properly validate level 2 page table entries, which allows local PV guest administrators to gain privileges via a crafted superpage mapping (CVE-2015-7835). Multiple memory leaks in Xen 4.0 through 4.6.x allow local guest administrators or domains with certain permission to cause a denial of service (memory consumption) via a large number of "teardowns" of domains with the vcpu pointer array allocated using the (1) XEN_DOMCTL_max_vcpus hypercall or the xenoprofile state vcpu pointer array allocated using the (2) XENOPROF_get_buffer or (3) XENOPROF_set_passive hypercall (CVE-2015-7969). The p2m_pod_emergency_sweep function in arch/x86/mm/p2m-pod.c in Xen 3.4.x, 3.5.x, and 3.6.x is not preemptible, which allows local x86 HVM guest administrators to cause a denial of service (CPU consumption and possibly reboot) via crafted memory contents that triggers a "time-consuming linear scan," related to Populate-on-Demand (CVE-2015-7970). Xen 3.2.x through 4.6.x does not limit the number of printk console messages when logging certain pmu and profiling hypercalls, which allows local guests to cause a denial of service via a sequence of crafted (1) HYPERCALL_xenoprof_op hypercalls, which are not properly handled in the do_xenoprof_op function in common/xenoprof.c, or (2) HYPERVISOR_xenpmu_op hypercalls, which are not properly handled in the do_xenpmu_op function in arch/x86/cpu/vpmu.c (CVE-2015-7971). The (1) libxl_set_memory_target function in tools/libxl/libxl.c and (2) libxl__build_post function in tools/libxl/libxl_dom.c in Xen 3.4.x through 4.6.x do not properly calculate the balloon size when using the populate-on-demand (PoD) system, which allows local HVM guest users to cause a denial of service (guest crash) via unspecified vectors related to "heavy memory pressure." (CVE-2015-7972) References: http://xenbits.xen.org/xsa/advisory-117.html http://xenbits.xen.org/xsa/advisory-118.html http://xenbits.xen.org/xsa/advisory-119.html http://xenbits.xen.org/xsa/advisory-120.html http://xenbits.xen.org/xsa/advisory-121.html http://xenbits.xen.org/xsa/advisory-122.html http://xenbits.xen.org/xsa/advisory-123.html http://xenbits.xen.org/xsa/advisory-124.html http://xenbits.xen.org/xsa/advisory-125.html http://xenbits.xen.org/xsa/advisory-126.html http://xenbits.xen.org/xsa/advisory-127.html http://xenbits.xen.org/xsa/advisory-128.html http://xenbits.xen.org/xsa/advisory-129.html http://xenbits.xen.org/xsa/advisory-130.html http://xenbits.xen.org/xsa/advisory-131.html http://xenbits.xen.org/xsa/advisory-132.html http://xenbits.xen.org/xsa/advisory-133.html http://xenbits.xen.org/xsa/advisory-134.html http://xenbits.xen.org/xsa/advisory-135.html http://xenbits.xen.org/xsa/advisory-136.html http://xenbits.xen.org/xsa/advisory-137.html http://xenbits.xen.org/xsa/advisory-138.html http://xenbits.xen.org/xsa/advisory-139.html http://xenbits.xen.org/xsa/advisory-140.html http://xenbits.xen.org/xsa/advisory-141.html http://xenbits.xen.org/xsa/advisory-142.html http://xenbits.xen.org/xsa/advisory-145.html http://xenbits.xen.org/xsa/advisory-146.html http://xenbits.xen.org/xsa/advisory-147.html http://xenbits.xen.org/xsa/advisory-148.html http://xenbits.xen.org/xsa/advisory-149.html http://xenbits.xen.org/xsa/advisory-150.html http://xenbits.xen.org/xsa/advisory-151.html http://xenbits.xen.org/xsa/advisory-152.html http://xenbits.xen.org/xsa/advisory-153.html
Whiteboard: feedback => (none)
URL: (none) => http://lwn.net/Vulnerabilities/662794/
Now when I run "xl create hvmtest -c -d -V", the host reboots. I don't see anything that looks remotely useful in any of the logs. Looks like it did a hard reboot, as booting my regular usage install had to recover the journal for the partition that I use for xen testing.
XSA-156 fix added for CVE-2015-5307 and CVE-2015-8104 packages for test: SRPM: xen-4.5.2-1.1.mga5.src.rpm i586: libxen3.0-4.5.2-1.1.mga5.i586.rpm libxen-devel-4.5.2-1.1.mga5.i586.rpm ocaml-xen-4.5.2-1.1.mga5.i586.rpm ocaml-xen-devel-4.5.2-1.1.mga5.i586.rpm xen-4.5.2-1.1.mga5.i586.rpm xen-doc-4.5.2-1.1.mga5.i586.rpm xen-hypervisor-4.5.2-1.1.mga5.i586.rpm x86_64: lib64xen3.0-4.5.2-1.1.mga5.x86_64.rpm lib64xen-devel-4.5.2-1.1.mga5.x86_64.rpm ocaml-xen-4.5.2-1.1.mga5.x86_64.rpm ocaml-xen-devel-4.5.2-1.1.mga5.x86_64.rpm xen-4.5.2-1.1.mga5.x86_64.rpm xen-doc-4.5.2-1.1.mga5.x86_64.rpm xen-hypervisor-4.5.2-1.1.mga5.x86_64.rpm I'll provide an updated advisory tonight
Updated advisory (also added to svn) This xen update is based on upstream 4.5.2 maintenance release, and fixes the following security issues: The vgic_v2_to_sgi function in arch/arm/vgic-v2.c in Xen 4.5.x, when running on ARM hardware with general interrupt controller (GIC) version 2, allows local guest users to cause a denial of service (host crash) by writing an invalid value to the GICD.SGIR register (CVE-2015-0268). The ARM GIC distributor virtualization in Xen 4.4.x and 4.5.x allows local guests to cause a denial of service by causing a large number messages to be logged (CVE-2015-1563). The emulation routines for unspecified X86 devices in Xen 3.2.x through 4.5.x does not properly initialize data, which allow local HVM guest users to obtain sensitive information via vectors involving an unsupported access size (CVE-2015-2044). The HYPERVISOR_xen_version hypercall in Xen 3.2.x through 4.5.x does not properly initialize data structures, which allows local guest users to obtain sensitive information via unspecified vectors (CVE-2015-2045). Xen 3.3.x through 4.5.x and the Linux kernel through 3.19.1 do not properly restrict access to PCI command registers, which might allow local guest users to cause a denial of service (non-maskable interrupt and host crash) by disabling the (1) memory or (2) I/O decoding for a PCI Express device and then accessing the device, which triggers an Unsupported Request (UR) response (CVE-2015-2150). The x86 emulator in Xen 3.2.x through 4.5.x does not properly ignore segment overrides for instructions with register operands, which allows local guest users to obtain sensitive information, cause a denial of service (memory corruption), or possibly execute arbitrary code via unspecified vectors (CVE-2015-2151). Xen 4.5.x and earlier enables certain default backends when emulating a VGA device for an x86 HVM guest qemu even when the configuration disables them, which allows local guest users to obtain access to the VGA console by (1) setting the DISPLAY environment variable, when compiled with SDL support, or connecting to the VNC server on (2) ::1 or (3) 127.0.0.1, when not compiled with SDL support (CVE-2015-2152). Xen 4.3.x, 4.4.x, and 4.5.x, when using toolstack disaggregation, allows remote domains with partial management control to cause a denial of service (host lock) via unspecified domctl operations (CVE-2015-2751). The XEN_DOMCTL_memory_mapping hypercall in Xen 3.2.x through 4.5.x, when using a PCI passthrough device, is not preemptable, which allows local x86 HVM domain users to cause a denial of service (host CPU consumption) via a crafted request to the device model (qemu-dm) (CVE-2015-2752). QEMU, as used in Xen 3.3.x through 4.5.x, does not properly restrict access to PCI command registers, which might allow local HVM guest users to cause a denial of service (non-maskable interrupt and host crash) by disabling the (1) memory or (2) I/O decoding for a PCI Express device and then accessing the device, which triggers an Unsupported Request (UR) response (CVE-2015-2756). Heap-based buffer overflow in the PCNET controller in QEMU allows remote attackers to execute arbitrary code by sending a packet with TXSTATUS_STARTPACKET set and then a crafted packet with TXSTATUS_DEVICEOWNS set (CVE-2015-3209). Stack-based buffer overflow in the xl command line utility in Xen 4.1.x through 4.5.x allows local guest administrators to gain privileges via a long configuration argument (CVE-2015-3259). Xen 4.2.x through 4.5.x does not initialize certain fields, which allows certain remote service domains to obtain sensitive information from memory via a (1) XEN_DOMCTL_gettscinfo or (2) XEN_SYSCTL_getdomaininfolist request (CVE-2015-3340). The Floppy Disk Controller (FDC) in QEMU, as used in Xen 4.5.x and earlier and KVM, allows local guest users to cause a denial of service (out-of-bounds write and guest crash) or possibly execute arbitrary code via the (1) FD_CMD_READ_ID, (2) FD_CMD_DRIVE_SPECIFICATION_COMMAND, or other unspecified commands, aka VENOM (CVE-2015-3456). Xen 3.3.x through 4.5.x does not properly restrict write access to the host MSI message data field, which allows local x86 HVM guest administrators cause a denial of service (host interrupt handling confusion) via vectors related to qemu and accessing spanning multiple fields (CVE-2015-4103). Xen 3.3.x through 4.5.x does not properly restrict access to PCI MSI mask bits, which allows local x86 HVM guest users to cause a denial of service (unexpected interrupt and host crash) via unspecified vectors (CVE-2015-4104). Xen 3.3.x through 4.5.x enables logging for PCI MSI-X pass-through error messages, which allows local x86 HVM guests to cause a denial of service (host disk consumption) via certain invalid operations (CVE-2015-4105). QEMU does not properly restrict write access to the PCI config space for certain PCI pass-through devices, which mighy allow local x86 HVM guests to gain privileges, cause a denial of service (host crash), obtain sensitive information, or possibly have other unspecified impact via unknown vectors (CVE-2015-4106). GNTTABOP_swap_grant_ref in Xen 4.2 through 4.5 does not check the grant table operation version, which allows local guest domains to cause a denial of service (NULL pointer dereference) via a hypercall without a GNTTABOP_setup_table or GNTTABOP_set_version (CVE-2015-4163). The compat_iret function in Xen 3.1 through 4.5 iterates the wrong way through a loop, which allows local 32-bit PV guest administrators to cause a denial of service (large loop and system hang) via a hypercall_iret call with EFLAGS.VM set (CVE-2015-4164). Heap-based buffer overflow in the IDE subsystem in QEMU, as used in Xen 4.5.x and earlier, when the container has a CDROM drive enabled, allows local guest users to execute arbitrary code on the host via unspecified ATAPI commands (CVE-2015-5154). The C+ mode offload emulation in the RTL8139 network card device model in QEMU, as used in Xen 4.5.x and earlier, allows remote attackers to read process heap memory via unspecified vectors (CVE-2015-5165). Use-after-free vulnerability in QEMU in Xen 4.5.x and earlier does not completely unplug emulated block devices, which allows local HVM guest users to gain privileges by unplugging a block device twice (CVE-2015-5166). A guest to host DoS issue was found affecting various hypervisors. In that, a guest can DoS the host by triggering an infinite stream of "alignment check" (#AC) exceptions. This causes the microcode to enter an infinite loop where the core never receives another interrupt. The host kernel panics due to this effect (CVE-2015-5307). The xenmem_add_to_physmap_one function in arch/arm/mm.c in Xen 4.5.x, 4.4.x, and earlier does not limit the number of printk console messages when reporting a failure to retrieve a reference on a foreign page, which allows remote domains to cause a denial of service by leveraging permissions to map the memory of a foreign guest (CVE-2015-6654). libxl in Xen 4.1.x through 4.6.x does not properly handle the readonly flag on disks when using the qemu-xen device model, which allows local guest users to write to a read-only disk image (CVE-2015-7311). Multicall support for arm in xen 4.4.x and later was not correctly set up with correct functionality and therefore exposed to guests a code path which crashes the host. Any guest can issue a preemptable hypercall via the multicall interface to exploit this vulnerability (CVE-2015-7812). Xen 4.4.x, 4.5.x, and 4.6.x does not limit the number of printk console messages when reporting unimplemented hypercalls, which allows local guests to cause a denial of service via a sequence of (1) HYPERVISOR_physdev_op hypercalls, which are not properly handled in the do_physdev_op function in arch/arm/physdev.c, or (2) HYPERVISOR_hvm_op hypercalls, which are not properly handled in the do_hvm_op function in arch/arm/hvm.c (CVE-2015-7813). Race condition in the relinquish_memory function in arch/arm/domain.c in Xen 4.6.x and earlier allows local domains with partial management control to cause a denial of service (host crash) via vectors involving the destruction of a domain and using XENMEM_decrease_reservation to reduce the memory of the domain (CVE-2015-7814). The mod_l2_entry function in arch/x86/mm.c in Xen 3.4 through 4.6.x does not properly validate level 2 page table entries, which allows local PV guest administrators to gain privileges via a crafted superpage mapping (CVE-2015-7835). Multiple memory leaks in Xen 4.0 through 4.6.x allow local guest administrators or domains with certain permission to cause a denial of service (memory consumption) via a large number of "teardowns" of domains with the vcpu pointer array allocated using the (1) XEN_DOMCTL_max_vcpus hypercall or the xenoprofile state vcpu pointer array allocated using the (2) XENOPROF_get_buffer or (3) XENOPROF_set_passive hypercall (CVE-2015-7969). The p2m_pod_emergency_sweep function in arch/x86/mm/p2m-pod.c in Xen 3.4.x, 3.5.x, and 3.6.x is not preemptible, which allows local x86 HVM guest administrators to cause a denial of service (CPU consumption and possibly reboot) via crafted memory contents that triggers a "time-consuming linear scan," related to Populate-on-Demand (CVE-2015-7970). Xen 3.2.x through 4.6.x does not limit the number of printk console messages when logging certain pmu and profiling hypercalls, which allows local guests to cause a denial of service via a sequence of crafted (1) HYPERCALL_xenoprof_op hypercalls, which are not properly handled in the do_xenoprof_op function in common/xenoprof.c, or (2) HYPERVISOR_xenpmu_op hypercalls, which are not properly handled in the do_xenpmu_op function in arch/x86/cpu/vpmu.c (CVE-2015-7971). The (1) libxl_set_memory_target function in tools/libxl/libxl.c and (2) libxl__build_post function in tools/libxl/libxl_dom.c in Xen 3.4.x through 4.6.x do not properly calculate the balloon size when using the populate-on-demand (PoD) system, which allows local HVM guest users to cause a denial of service (guest crash) via unspecified vectors related to "heavy memory pressure." (CVE-2015-7972) A guest to host DoS issue was found affecting various hypervisors. In that, a guest can DoS the host by triggering an infinite stream of "debug check" (#DB) exceptions. This causes the microcode to enter an infinite loop where the core never receives another interrupt. The host kernel panics due to this effect (CVE-2015-8104). For other fixes in this update, see the referenced changelogs. References: - https://bugs.mageia.org/show_bug.cgi?id=16956 - http://xenbits.xen.org/xsa/advisory-117.html - http://xenbits.xen.org/xsa/advisory-118.html - http://xenbits.xen.org/xsa/advisory-119.html - http://xenbits.xen.org/xsa/advisory-120.html - http://xenbits.xen.org/xsa/advisory-121.html - http://xenbits.xen.org/xsa/advisory-122.html - http://xenbits.xen.org/xsa/advisory-123.html - http://xenbits.xen.org/xsa/advisory-124.html - http://xenbits.xen.org/xsa/advisory-125.html - http://xenbits.xen.org/xsa/advisory-126.html - http://xenbits.xen.org/xsa/advisory-127.html - http://xenbits.xen.org/xsa/advisory-128.html - http://xenbits.xen.org/xsa/advisory-129.html - http://xenbits.xen.org/xsa/advisory-130.html - http://xenbits.xen.org/xsa/advisory-131.html - http://xenbits.xen.org/xsa/advisory-132.html - http://xenbits.xen.org/xsa/advisory-133.html - http://xenbits.xen.org/xsa/advisory-134.html - http://xenbits.xen.org/xsa/advisory-135.html - http://xenbits.xen.org/xsa/advisory-136.html - http://xenbits.xen.org/xsa/advisory-137.html - http://xenbits.xen.org/xsa/advisory-138.html - http://xenbits.xen.org/xsa/advisory-139.html - http://xenbits.xen.org/xsa/advisory-140.html - http://xenbits.xen.org/xsa/advisory-141.html - http://xenbits.xen.org/xsa/advisory-142.html - http://xenbits.xen.org/xsa/advisory-145.html - http://xenbits.xen.org/xsa/advisory-146.html - http://xenbits.xen.org/xsa/advisory-147.html - http://xenbits.xen.org/xsa/advisory-148.html - http://xenbits.xen.org/xsa/advisory-149.html - http://xenbits.xen.org/xsa/advisory-150.html - http://xenbits.xen.org/xsa/advisory-151.html - http://xenbits.xen.org/xsa/advisory-152.html - http://xenbits.xen.org/xsa/advisory-153.html - http://xenbits.xen.org/xsa/advisory-156.html - http://www.xenproject.org/downloads/xen-archives/xen-45-series/xen-451.html - http://www.xenproject.org/downloads/xen-archives/xen-45-series/xen-452.html
Whiteboard: (none) => advisory
Back to the same problem as in comment 8, where the installer starts, but the xl command ends when the guest tries to scan for usb devices.
Whiteboard: advisory => advisory feedback
@Dave, what kernel is you running on the host ?
From /boot/grub/menu.lst ... title xen 4.1.13 4.1.13-2.mga5 kernel (hd0,5)/boot/xen.gz dom0_mem=4096MB module (hd0,5)/boot/vmlinuz-4.1.13-server-2.mga5 BOOT_IMAGE=server_4.1.13-2.mga5 root=UUID=e51ada81-ec21-456e-a2f4-513f3e8cae68 noiswmd resume=UUID=9af64cdc-a611-47c3-821e-94a9fd60251e vga=788 root (hd0,5) module /boot/initrd-4.1.13-server-2.mga5.img In /boot, /boot/xen.gz -> xen-4.5.2.gz
http://lwn.net/Vulnerabilities/668334/ There have been several more XSAs lately. Thomas said he would try to work on this again this weekend.
Ok, all known XSAs merged along with a few more fixes: - memory: split and tighten maximum order permitted in memops (CVE-2015-8338 / XSA-158) - memory: fix XENMEM_exchange error handling (CVE-2015-8339 + CVE-2015-8340 / XSA-159) - libxl: Fix bootloader-related virtual memory leak on pv build failure - x86/PoD: Make p2m_pod_empty_cache() restartable - x86/vmx: improvements to vmentry failure handling - x86/HVM: don't inject #DB with error code - VMX: fix/adjust trap injection - sched: fix locking for insert_vcpu() in credit1 and RTDS - x86/vPMU: document as unsupported (XSA-163) - x86/boot: check for not allowed sections before linking - x86/ept: remove unnecessary sync after resolving misconfigured entries - evtchn: don't reuse ports that are still "busy" - VT-d: drop unneeded Ivybridge quirk workaround - x86/time: fix domain type check in tsc_set_info() - x86: don't leak ST(n)/XMMn values to domains first using them (CVE-2015-8555 / XSA-165) - x86/HVM: avoid reading ioreq state more than once (XSA-166) - net: pcnet: add check to validate receive data size (XSA-162 / CVE-2015-7504) - MSI-X: avoid array overrun upon MSI-X table writes (XSA-164 / CVE pending) - x86: make debug output consistent in hvm_set_callback_via (XSA-169 / CVE pending) I will post a better advisory later... SRPMS: xen-4.5.2-1.2.mga5.src.rpm i586: libxen3.0-4.5.2-1.2.mga5.i586.rpm libxen-devel-4.5.2-1.2.mga5.i586.rpm ocaml-xen-4.5.2-1.2.mga5.i586.rpm ocaml-xen-devel-4.5.2-1.2.mga5.i586.rpm xen-4.5.2-1.2.mga5.i586.rpm xen-doc-4.5.2-1.2.mga5.i586.rpm xen-hypervisor-4.5.2-1.2.mga5.i586.rpm x86_64: lib64xen3.0-4.5.2-1.2.mga5.x86_64.rpm lib64xen-devel-4.5.2-1.2.mga5.x86_64.rpm ocaml-xen-4.5.2-1.2.mga5.x86_64.rpm ocaml-xen-devel-4.5.2-1.2.mga5.x86_64.rpm xen-4.5.2-1.2.mga5.x86_64.rpm xen-doc-4.5.2-1.2.mga5.x86_64.rpm xen-hypervisor-4.5.2-1.2.mga5.x86_64.rpm
Whiteboard: advisory feedback => advisory
Gah, realized I missed one XSA while working on new kernel... - paravirtualized drivers incautious about shared memory contents (CVE-2015-8550 / XSA-155) So packages to test (currently building): SRPMS: xen-4.5.2-1.3.mga5.src.rpm i586: libxen3.0-4.5.2-1.3.mga5.i586.rpm libxen-devel-4.5.2-1.3.mga5.i586.rpm ocaml-xen-4.5.2-1.3.mga5.i586.rpm ocaml-xen-devel-4.5.2-1.3.mga5.i586.rpm xen-4.5.2-1.3.mga5.i586.rpm xen-doc-4.5.2-1.3.mga5.i586.rpm xen-hypervisor-4.5.2-1.3.mga5.i586.rpm x86_64: lib64xen3.0-4.5.2-1.3.mga5.x86_64.rpm lib64xen-devel-4.5.2-1.3.mga5.x86_64.rpm ocaml-xen-4.5.2-1.3.mga5.x86_64.rpm ocaml-xen-devel-4.5.2-1.3.mga5.x86_64.rpm xen-4.5.2-1.3.mga5.x86_64.rpm xen-doc-4.5.2-1.3.mga5.x86_64.rpm xen-hypervisor-4.5.2-1.3.mga5.x86_64.rpm
advisory in svn updated according to fixes added in comment 20 and comment 21
Two more security issues exited embargo today: The PV superpage functionality lacks certain validity checks on data being passed to the hypervisor by guests. This is the case for the page identifier (MFN) passed to MMUEXT_MARK_SUPER and MMUEXT_UNMARK_SUPER sub-ops of the HYPERVISOR_mmuext_op hypercall as well as for various forms of page table updates. Use of the feature, which is disabled by default, may have unknown effects, ranging from information leaks through Denial of Service to privilege escalation. (CVE-2016-1570) While INVLPG does not cause a General Protection Fault when used on a non-canonical address, INVVPID in its "individual address" variant, which is used to back the intercepted INVLPG in certain cases, fails in such cases. Failure of INVVPID results in a hypervisor bug check. A malicious guest can crash the host, leading to a Denial of Service. (CVE-2016-1571) advisory in svn updated accordingly SRPMS: xen-4.5.2-1.4.mga5.src.rpm i586: libxen3.0-4.5.2-1.4.mga5.i586.rpm libxen-devel-4.5.2-1.4.mga5.i586.rpm ocaml-xen-4.5.2-1.4.mga5.i586.rpm ocaml-xen-devel-4.5.2-1.4.mga5.i586.rpm xen-4.5.2-1.4.mga5.i586.rpm xen-doc-4.5.2-1.4.mga5.i586.rpm xen-hypervisor-4.5.2-1.4.mga5.i586.rpm x86_64: lib64xen3.0-4.5.2-1.4.mga5.x86_64.rpm lib64xen-devel-4.5.2-1.4.mga5.x86_64.rpm ocaml-xen-4.5.2-1.4.mga5.x86_64.rpm ocaml-xen-devel-4.5.2-1.4.mga5.x86_64.rpm xen-4.5.2-1.4.mga5.x86_64.rpm xen-doc-4.5.2-1.4.mga5.x86_64.rpm xen-hypervisor-4.5.2-1.4.mga5.x86_64.rpm
I got as far as loading the Xen module - but running xen inside of a VirtualBox VM may be giving an issue - no screen. This is my grub entry: title XEN server 4.1.13-2.mga5 kernel (hd0,0)/boot/xen.gz dom0_mem=2048M,max:2048M loglvl=all guest_loglvl=all module (hd0,0)/boot/vmlinuz-4.1.13-server-2.mga5 BOOT_IMAGE=server_4.1.13-2.mga5 root=UUID=4d95d47d-4d08-4069-827d-d8ce3dab4323 splash quiet noiswmd resume=UUID=12f65877-1ad2-4a8f-97cd-1d8720e0aabf vga=788 root (hd0,0) module (hd0,0)/boot/initrd.img I've tried different combinations, no luck. Think it has to be on physical hardware. Any suggestions are welcome. It has been an interesting journey. FYI - URLS that helped so far: https://wiki.mageia.org/en/XEN https://agentoss.wordpress.com/2014/03/05/mageia-4-xen-server/ https://wiki.centos.org/HowTos/Xen/Xen4QuickStart
CC: (none) => brtians1
I'm still getting the problem described in Comment 8 where the guest starts, but then the "xl create" terminates, as soon as the guest starts scanning for usb devices. Brian, xen must be run on real hardware, it will not run inside of vb.
Adding feedback marker.
Added fixes for the security issues: Xen 4.6.x and earlier allows local guest administrators to cause a denial of service (host reboot) via vectors related to multiple mappings of MMIO pages with different cachability settings (CVE-2016-2270). VMX in Xen 4.6.x and earlier, when using an Intel or Cyrix CPU, allows local HVM guest users to cause a denial of service (guest crash) via vectors related to a non-canonical RIP (CVE-2016-2271). dropped reference to xsa-169 that does not affect xen-4.5 branch added fixes from upstream 4.5 stable branch: - x86/mmuext: tighten TLB flush address checks - x86: fix (and simplify) MTRR overlap checking - x86/vmx: don't clobber exception_bitmap when entering/leaving emulated real mode - credit: update timeslice under lock - credit: recalculate per-cpupool credits when updating timeslice - x86/nHVM: avoid NULL deref during INVLPG intercept handling - hvmloader: fix scratch_alloc to avoid overlaps - xen/arm64: Make sure we get all debug output - x86: fix unintended fallthrough case from XSA-154 advisory in svn updated accordingly. Packages for test: SRPMS: xen-4.5.2-1.5.mga5.src.rpm i586: libxen3.0-4.5.2-1.5.mga5.i586.rpm libxen-devel-4.5.2-1.5.mga5.i586.rpm ocaml-xen-4.5.2-1.5.mga5.i586.rpm ocaml-xen-devel-4.5.2-1.5.mga5.i586.rpm xen-4.5.2-1.5.mga5.i586.rpm xen-doc-4.5.2-1.5.mga5.i586.rpm xen-hypervisor-4.5.2-1.5.mga5.i586.rpm x86_64: lib64xen3.0-4.5.2-1.5.mga5.x86_64.rpm lib64xen-devel-4.5.2-1.5.mga5.x86_64.rpm ocaml-xen-4.5.2-1.5.mga5.x86_64.rpm ocaml-xen-devel-4.5.2-1.5.mga5.x86_64.rpm xen-4.5.2-1.5.mga5.x86_64.rpm xen-doc-4.5.2-1.5.mga5.x86_64.rpm xen-hypervisor-4.5.2-1.5.mga5.x86_64.rpm
ok - installed the modules in x86_64. That went fine. Managed to get it to grub load with he following title Xen_build kernel (hd0,0)/boot/xen.gz dom0_mem=1024M,max:4084M loglvl=all guest_loglvl=all module (hd0,0)/boot/vmlinuz-4.1.15-desktop-2.mga5 BOOT_IMAGE=desktop_4.1.15-2.mga5 root=UUID=d1dc9c80-f2c8-45e9-bc22-873e75be3bcf splash quiet noiswmd resume=UUID=24b4cd5a-0a6e-41a5-b02e-087f372f1783 vga=788 root (hd0,0) module (hd0,0)/boot/initrd.img confirmed it is running [root@localhost grub]# ps -ef | grep xen root 22 2 0 08:57 ? 00:00:00 [xenwatch] root 23 2 0 08:57 ? 00:00:00 [xenbus] root 31 2 0 08:57 ? 00:00:00 [xenbus_frontend] root 463 2 0 08:57 ? 00:00:00 [xen_pciback_wor] root 803 1 0 08:57 ? 00:00:00 /usr/sbin/oxenstored --no-fork root 830 1 0 08:57 ? 00:00:00 /usr/sbin/xenconsoled --pid-file /var/run/xen/xenconsoled.pid --log=none --log-dir=/var/log/xen/console root 906 1 0 08:57 ? 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 root 2828 2746 0 09:05 pts/0 00:00:00 grep --color xen I'll start building a VM now.
okay - installed Virtual Machine Manager. Booted up an iso of puppy Linux - worked ok Installed another VM for Linux Mint 17 - Mate Both worked. I didn't set up networking so that module wasn't tested. Also increased dom0_mem from 1024M to 4084, that made 4 GB of RAM available. I think it is working. Giving it a thumbs up for x86_64
Whiteboard: advisory => advisory MGA5_64_OK
Whiteboard: advisory MGA5_64_OK => advisory MGA5-64-OK
Looks good Brian, well done. Think we finally have a procedure for this one :) Validating.
Keywords: (none) => validated_updateWhiteboard: advisory MGA5-64-OK => has_procedure advisory MGA5-64-OKCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2016-0098.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
A couple more LWN references: http://lwn.net/Vulnerabilities/677982/ http://lwn.net/Vulnerabilities/679131/