{"id":"MGASA-2016-0098","summary":"Updated xen packages fix security vulnerabilities","details":"This xen update is based on upstream 4.5.2 maintenance release, and fixes the\nfollowing security issues:\n\nThe vgic_v2_to_sgi function in arch/arm/vgic-v2.c in Xen 4.5.x, when running\non ARM hardware with general interrupt controller (GIC) version 2, allows\nlocal guest users to cause a denial of service (host crash) by writing an\ninvalid value to the GICD.SGIR register (CVE-2015-0268).\n\nThe ARM GIC distributor virtualization in Xen 4.4.x and 4.5.x allows local\nguests to cause a denial of service by causing a large number messages to\nbe logged (CVE-2015-1563).\n\nThe emulation routines for unspecified X86 devices in Xen 3.2.x through\n4.5.x does not properly initialize data, which allow local HVM guest users\nto obtain sensitive information via vectors involving an unsupported access\nsize (CVE-2015-2044).\n\nThe HYPERVISOR_xen_version hypercall in Xen 3.2.x through 4.5.x does not\nproperly initialize data structures, which allows local guest users to\nobtain sensitive information via unspecified vectors (CVE-2015-2045).\n\nXen 3.3.x through 4.5.x and the Linux kernel through 3.19.1 do not properly\nrestrict access to PCI command registers, which might allow local guest\nusers to cause a denial of service (non-maskable interrupt and host crash)\nby disabling the (1) memory or (2) I/O decoding for a PCI Express device\nand then accessing the device, which triggers an Unsupported Request (UR)\nresponse (CVE-2015-2150).\n\nThe x86 emulator in Xen 3.2.x through 4.5.x does not properly ignore segment\noverrides for instructions with register operands, which allows local guest\nusers to obtain sensitive information, cause a denial of service (memory\ncorruption), or possibly execute arbitrary code via unspecified vectors\n(CVE-2015-2151).\n\nXen 4.5.x and earlier enables certain default backends when emulating a VGA\ndevice for an x86 HVM guest qemu even when the configuration disables them,\nwhich allows local guest users to obtain access to the VGA console by (1)\nsetting the DISPLAY environment variable, when compiled with SDL support,\nor connecting to the VNC server on (2) ::1 or (3) 127.0.0.1, when not\ncompiled with SDL support (CVE-2015-2152).\n\nXen 4.3.x, 4.4.x, and 4.5.x, when using toolstack disaggregation, allows\nremote domains with partial management control to cause a denial of service\n(host lock) via unspecified domctl operations (CVE-2015-2751). \n\nThe XEN_DOMCTL_memory_mapping hypercall in Xen 3.2.x through 4.5.x, when\nusing a PCI passthrough device, is not preemptable, which allows local x86\nHVM domain users to cause a denial of service (host CPU consumption) via\na crafted request to the device model (qemu-dm) (CVE-2015-2752).\n\nQEMU, as used in Xen 3.3.x through 4.5.x, does not properly restrict access\nto PCI command registers, which might allow local HVM guest users to cause\na denial of service (non-maskable interrupt and host crash) by disabling\nthe (1) memory or (2) I/O decoding for a PCI Express device and then\naccessing the device, which triggers an Unsupported Request (UR) response\n(CVE-2015-2756).\n\nHeap-based buffer overflow in the PCNET controller in QEMU allows remote\nattackers to execute arbitrary code by sending a packet with\nTXSTATUS_STARTPACKET set and then a crafted packet with TXSTATUS_DEVICEOWNS\nset (CVE-2015-3209).\n\nStack-based buffer overflow in the xl command line utility in Xen 4.1.x\nthrough 4.5.x allows local guest administrators to gain privileges via a\nlong configuration argument (CVE-2015-3259).\n\nXen 4.2.x through 4.5.x does not initialize certain fields, which allows\ncertain remote service domains to obtain sensitive information from memory\nvia a (1) XEN_DOMCTL_gettscinfo or (2) XEN_SYSCTL_getdomaininfolist request\n(CVE-2015-3340).\n\nThe Floppy Disk Controller (FDC) in QEMU, as used in Xen 4.5.x and earlier\nand KVM, allows local guest users to cause a denial of service (out-of-bounds\nwrite and guest crash) or possibly execute arbitrary code via the (1)\nFD_CMD_READ_ID, (2) FD_CMD_DRIVE_SPECIFICATION_COMMAND, or other unspecified\ncommands, aka VENOM (CVE-2015-3456).\n\nXen 3.3.x through 4.5.x does not properly restrict write access to the host\nMSI message data field, which allows local x86 HVM guest administrators\ncause a denial of service (host interrupt handling confusion) via vectors\nrelated to qemu and accessing spanning multiple fields (CVE-2015-4103).\n\nXen 3.3.x through 4.5.x does not properly restrict access to PCI MSI mask\nbits, which allows local x86 HVM guest users to cause a denial of service\n(unexpected interrupt and host crash) via unspecified vectors \n(CVE-2015-4104).\n\nXen 3.3.x through 4.5.x enables logging for PCI MSI-X pass-through error\nmessages, which allows local x86 HVM guests to cause a denial of service\n(host disk consumption) via certain invalid operations (CVE-2015-4105).\n\nQEMU does not properly restrict write access to the PCI config space for\ncertain PCI pass-through devices, which mighy allow local x86 HVM guests\nto gain privileges, cause a denial of service (host crash), obtain\nsensitive information, or possibly have other unspecified impact via\nunknown vectors (CVE-2015-4106).\n\nGNTTABOP_swap_grant_ref in Xen 4.2 through 4.5 does not check the grant\ntable operation version, which allows local guest domains to cause a\ndenial of service (NULL pointer dereference) via a hypercall without a\nGNTTABOP_setup_table or GNTTABOP_set_version (CVE-2015-4163).\n\nThe compat_iret function in Xen 3.1 through 4.5 iterates the wrong way\nthrough a loop, which allows local 32-bit PV guest administrators to cause\na denial of service (large loop and system hang) via a hypercall_iret call\nwith EFLAGS.VM set (CVE-2015-4164).\n\nHeap-based buffer overflow in the IDE subsystem in QEMU, as used in Xen\n4.5.x and earlier, when the container has a CDROM drive enabled, allows\nlocal guest users to execute arbitrary code on the host via unspecified\nATAPI commands (CVE-2015-5154).\n\nThe C+ mode offload emulation in the RTL8139 network card device model in\nQEMU, as used in Xen 4.5.x and earlier, allows remote attackers to read\nprocess heap memory via unspecified vectors (CVE-2015-5165).\n\nUse-after-free vulnerability in QEMU in Xen 4.5.x and earlier does not\ncompletely unplug emulated block devices, which allows local HVM guest\nusers to gain privileges by unplugging a block device twice (CVE-2015-5166).\n\nA guest to host DoS issue was found affecting various hypervisors. In that,\na guest can DoS the host by triggering an infinite stream of \"alignment\ncheck\" (#AC) exceptions. This causes the microcode to enter an infinite loop\nwhere the core never receives another interrupt. The host kernel panics due\nto this effect (CVE-2015-5307).\n\nThe xenmem_add_to_physmap_one function in arch/arm/mm.c in Xen 4.5.x,\n4.4.x, and earlier does not limit the number of printk console messages\nwhen reporting a failure to retrieve a reference on a foreign page, which\nallows remote domains to cause a denial of service by leveraging\npermissions to map the memory of a foreign guest (CVE-2015-6654).\n\nlibxl in Xen 4.1.x through 4.6.x does not properly handle the readonly flag\non disks when using the qemu-xen device model, which allows local guest\nusers to write to a read-only disk image (CVE-2015-7311).\n\nA heap-based buffer overflow flaw was discovered in the way QEMU's AMD\nPC-Net II Ethernet Controller emulation received certain packets in\nloopback mode. A privileged user (with the CAP_SYS_RAWIO capability)\ninside a guest could use this flaw to crash the host QEMU process\n(resulting in denial of service) or, potentially, execute arbitrary\ncode with privileges of the host QEMU process (CVE-2015-7504).\n\nMulticall support for arm in xen 4.4.x and later was not correctly set\nup with correct functionality and therefore exposed to guests a code path\nwhich crashes the host. Any guest can issue a preemptable hypercall via the\nmulticall interface to exploit this vulnerability (CVE-2015-7812).\n\nXen 4.4.x, 4.5.x, and 4.6.x does not limit the number of printk console\nmessages when reporting unimplemented hypercalls, which allows local guests\nto cause a denial of service via a sequence of (1) HYPERVISOR_physdev_op\nhypercalls, which are not properly handled in the do_physdev_op function\nin arch/arm/physdev.c, or (2) HYPERVISOR_hvm_op hypercalls, which are not\nproperly handled in the do_hvm_op function in arch/arm/hvm.c (CVE-2015-7813).\n\nRace condition in the relinquish_memory function in arch/arm/domain.c in\nXen 4.6.x and earlier allows local domains with partial management control\nto cause a denial of service (host crash) via vectors involving the\ndestruction of a domain and using XENMEM_decrease_reservation to reduce\nthe memory of the domain (CVE-2015-7814).\n\nThe mod_l2_entry function in arch/x86/mm.c in Xen 3.4 through 4.6.x does\nnot properly validate level 2 page table entries, which allows local PV\nguest administrators to gain privileges via a crafted superpage mapping\n(CVE-2015-7835).\n\nMultiple memory leaks in Xen 4.0 through 4.6.x allow local guest\nadministrators or domains with certain permission to cause a denial of\nservice (memory consumption) via a large number of \"teardowns\" of domains\nwith the vcpu pointer array allocated using the (1) XEN_DOMCTL_max_vcpus\nhypercall or the xenoprofile state vcpu pointer array allocated using the\n(2) XENOPROF_get_buffer or (3) XENOPROF_set_passive hypercall\n(CVE-2015-7969).\n\nThe p2m_pod_emergency_sweep function in arch/x86/mm/p2m-pod.c in Xen 3.4.x,\n3.5.x, and 3.6.x is not preemptible, which allows local x86 HVM guest\nadministrators to cause a denial of service (CPU consumption and possibly\nreboot) via crafted memory contents that triggers a \"time-consuming linear\nscan,\" related to Populate-on-Demand (CVE-2015-7970).\n\nXen 3.2.x through 4.6.x does not limit the number of printk console messages\nwhen logging certain pmu and profiling hypercalls, which allows local guests\nto cause a denial of service via a sequence of crafted (1) \nHYPERCALL_xenoprof_op hypercalls, which are not properly handled in the \ndo_xenoprof_op function in common/xenoprof.c, or (2) HYPERVISOR_xenpmu_op\nhypercalls, which are not properly handled in the do_xenpmu_op function in\narch/x86/cpu/vpmu.c (CVE-2015-7971).\n\nThe (1) libxl_set_memory_target function in tools/libxl/libxl.c and (2) \nlibxl__build_post function in tools/libxl/libxl_dom.c in Xen 3.4.x through\n4.6.x do not properly calculate the balloon size when using the\npopulate-on-demand (PoD) system, which allows local HVM guest users to\ncause a denial of service (guest crash) via unspecified vectors related\nto \"heavy memory pressure.\" (CVE-2015-7972)\n\nA guest to host DoS issue was found affecting various hypervisors. In that,\na guest can DoS the host by triggering an infinite stream of \"debug check\"\n(#DB) exceptions. This causes the microcode to enter an infinite loop where\nthe core never receives another interrupt. The host kernel panics due to\nthis effect (CVE-2015-8104).\n\nXen 4.6.x and earlier does not properly enforce limits on page order inputs\nfor the (1) XENMEM_increase_reservation, (2) XENMEM_populate_physmap,\n(3) XENMEM_exchange, and possibly other HYPERVISOR_memory_op suboperations,\nwhich allows ARM guest OS administrators to cause a denial of service (CPU\nconsumption, guest reboot, or watchdog timeout and host reboot) and possibly\nhave unspecified other impact via unknown vectors (CVE-2015-8338).\n\nThe memory_exchange function in common/memory.c in Xen 3.2.x through 4.6.x\ndoes not properly hand back pages to a domain, which might allow guest OS\nadministrators to cause a denial of service (host crash) via unspecified\nvectors related to domain teardown (CVE-2015-8339).\n\nThe memory_exchange function in common/memory.c in Xen 3.2.x through 4.6.x\ndoes not properly release locks, which might allow guest OS administrators\nto cause a denial of service (deadlock or host crash) via unspecified\nvectors, related to XENMEM_exchange error handling (CVE-2015-8340).\n\nFelix Wilhelm discovered a race condition in the Xen paravirtualized\ndrivers which can cause double fetch vulnerabilities. An attacker in the\nparavirtualized guest could exploit this flaw to cause a denial of service\n(crash the host) or potentially execute arbitrary code on the host\n(CVE-2015-8550).\n\nInformation leak in legacy x86 FPU/XMM initialization (CVE-2015-8555).\n\nThe PV superpage functionality lacks certain validity checks on data\nbeing passed to the hypervisor by guests.  This is the case for the\npage identifier (MFN) passed to MMUEXT_MARK_SUPER and\nMMUEXT_UNMARK_SUPER sub-ops of the HYPERVISOR_mmuext_op hypercall as\nwell as for various forms of page table updates. Use of the feature,\nwhich is disabled by default, may have unknown effects, ranging from\ninformation leaks through Denial of Service to privilege escalation.\n(CVE-2016-1570)\n\nWhile INVLPG does not cause a General Protection Fault when used on a\nnon-canonical address, INVVPID in its \"individual address\" variant,\nwhich is used to back the intercepted INVLPG in certain cases, fails in\nsuch cases. Failure of INVVPID results in a hypervisor bug check.\nA malicious guest can crash the host, leading to a Denial of Service.\n(CVE-2016-1571)\n\nXen 4.6.x and earlier allows local guest administrators to cause a denial\nof service (host reboot) via vectors related to multiple mappings of MMIO\npages with different cachability settings (CVE-2016-2270).\n\nVMX in Xen 4.6.x and earlier, when using an Intel or Cyrix CPU, allows\nlocal HVM guest users to cause a denial of service (guest crash) via\nvectors related to a non-canonical RIP (CVE-2016-2271).\n\nFor other fixes in this update, see the referenced changelogs.\n","modified":"2026-02-04T04:26:38.026010Z","published":"2016-03-07T11:20:30Z","related":["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-5307","CVE-2015-6654","CVE-2015-7311","CVE-2015-7504","CVE-2015-7812","CVE-2015-7813","CVE-2015-7814","CVE-2015-7835","CVE-2015-7969","CVE-2015-7970","CVE-2015-7971","CVE-2015-7972","CVE-2015-8104","CVE-2015-8338","CVE-2015-8339","CVE-2015-8340","CVE-2015-8550","CVE-2015-8555","CVE-2016-1570","CVE-2016-1571","CVE-2016-2270","CVE-2016-2271"],"references":[{"type":"ADVISORY","url":"https://advisories.mageia.org/MGASA-2016-0098.html"},{"type":"REPORT","url":"https://bugs.mageia.org/show_bug.cgi?id=16956"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-117.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-118.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-119.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-120.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-121.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-122.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-123.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-124.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-125.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-126.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-127.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-128.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-129.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-130.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-131.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-132.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-133.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-134.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-135.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-136.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-137.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-138.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-139.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-140.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-141.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-142.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-145.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-146.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-147.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-148.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-149.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-150.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-151.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-152.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-153.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-154.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-155.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-156.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-158.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-159.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-162.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-163.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-164.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-165.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-166.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-167.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-168.html"},{"type":"REPORT","url":"http://xenbits.xen.org/xsa/advisory-170.html"},{"type":"REPORT","url":"http://www.xenproject.org/downloads/xen-archives/xen-45-series/xen-451.html"},{"type":"REPORT","url":"http://www.xenproject.org/downloads/xen-archives/xen-45-series/xen-452.html"}],"affected":[{"package":{"name":"xen","ecosystem":"Mageia:5","purl":"pkg:rpm/mageia/xen?arch=source&distro=mageia-5"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.5.2-1.5.mga5"}]}],"ecosystem_specific":{"section":"core"},"database_specific":{"source":"https://advisories.mageia.org/MGASA-2016-0098.json"}}],"schema_version":"1.7.3","credits":[{"name":"Mageia","contact":["https://wiki.mageia.org/en/Packages_Security_Team"],"type":"COORDINATOR"}]}