Attachment 158621 Details for Bug 201416 – security/vuxml update for xen

[patch] security/vuxml update for xen

xen-big-vuxml.diff (text/plain), 24.02 KB, created by Jason Unovitch on 2015-07-11 17:18:36 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Jason Unovitch

Created: 2015-07-11 17:18:36 UTC

Size: 24.02 KB

patch

obsolete

>Index: vuln.xml
>===================================================================
>--- vuln.xml	(revision 391739)
>+++ vuln.xml	(working copy)
>@@ -57,6 +57,610 @@
> 
> -->
> <vuxml xmlns="http://www.vuxml.org/apps/vuxml-1">
>+ <vuln vid="f1deed23-27ec-11e5-a4a5-002590263bf5">
>+ <topic>xen-tools -- xl command line config handling stack overflow</topic>
>+ <affects>
>+ <package>
>+	<name>xen-tools</name>
>+	<range><ge>4.1</ge><lt>4.5.0_8</lt></range>
>+ </package>
>+ </affects>
>+ <description>
>+ <body xmlns="http://www.w3.org/1999/xhtml">
>+	The Xen Project reports:
>+	<blockquote cite="http://xenbits.xen.org/xsa/advisory-137.html">
>+	 The xl command line utility mishandles long configuration values
>+	 when passed as command line arguments, with a buffer overrun.
>+	 A semi-trusted guest administrator or controller, who is intended
>+	 to be able to partially control the configuration settings for a
>+	 domain, can escalate their privileges to that of the whole host.
>+	</blockquote>
>+ </body>
>+ </description>
>+ <references>
>+ <cvename>CVE-2015-3259</cvename>
>+ <url>http://xenbits.xen.org/xsa/advisory-137.html</url>
>+ </references>
>+ <dates>
>+ <discovery>2015-07-07</discovery>
>+ <entry>2015-07-11</entry>
>+ </dates>
>+ </vuln>
>+
>+ <vuln vid="8c31b288-27ec-11e5-a4a5-002590263bf5">
>+ <topic>xen-kernel -- vulnerability in the iret hypercall handler</topic>
>+ <affects>
>+ <package>
>+	<name>xen-kernel</name>
>+	<range><ge>3.1</ge><lt>4.5.0_3</lt></range>
>+ </package>
>+ </affects>
>+ <description>
>+ <body xmlns="http://www.w3.org/1999/xhtml">
>+	The Xen Project reports:
>+	<blockquote cite="http://xenbits.xen.org/xsa/advisory-136.html">
>+	 A buggy loop in Xen's compat_iret() function iterates the wrong way
>+	 around a 32-bit index. Any 32-bit PV guest kernel can trigger this
>+	 vulnerability by attempting a hypercall_iret with EFLAGS.VM set.
>+	 Given the use of __get/put_user(), and that the virtual addresses
>+	 in question are contained within the lower canonical half, the guest
>+	 cannot clobber any hypervisor data. Instead, Xen will take up to
>+	 2^33 pagefaults, in sequence, effectively hanging the host.
>+	 Malicious guest administrators can cause a denial of service
>+	 affecting the whole system.
>+	</blockquote>
>+ </body>
>+ </description>
>+ <references>
>+ <cvename>CVE-2015-4164</cvename>
>+ <url>http://xenbits.xen.org/xsa/advisory-136.html</url>
>+ </references>
>+ <dates>
>+ <discovery>2015-06-11</discovery>
>+ <entry>2015-07-11</entry>
>+ </dates>
>+ </vuln>
>+
>+ <vuln vid="80e846ff-27eb-11e5-a4a5-002590263bf5">
>+ <topic>xen-kernel -- GNTTABOP_swap_grant_ref operation misbehavior</topic>
>+ <affects>
>+ <package>
>+	<name>xen-kernel</name>
>+	<range><ge>4.2</ge><lt>4.5.0_3</lt></range>
>+ </package>
>+ </affects>
>+ <description>
>+ <body xmlns="http://www.w3.org/1999/xhtml">
>+	The Xen Project reports:
>+	<blockquote cite="http://xenbits.xen.org/xsa/advisory-134.html">
>+	 With the introduction of version 2 grant table operations, a
>+	 version check became necessary for most grant table related
>+	 hypercalls. The GNTTABOP_swap_grant_ref call was lacking such a
>+	 check. As a result, the subsequent code behaved as if version 2 was
>+	 in use, when a guest issued this hypercall without a prior
>+	 GNTTABOP_setup_table or GNTTABOP_set_version.
>+	 The effect is a possible NULL pointer dereferences. However, this
>+	 cannot be exploited to elevate privileges of the attacking domain,
>+	 as the maximum memory address that can be wrongly accessed this way
>+	 is bounded to far below the start of hypervisor memory.
>+	 Malicious or buggy guest domain kernels can mount a denial of
>+	 service attack which, if successful, can affect the whole system.
>+	</blockquote>
>+ </body>
>+ </description>
>+ <references>
>+ <cvename>CVE-2015-4163</cvename>
>+ <url>http://xenbits.xen.org/xsa/advisory-134.html</url>
>+ </references>
>+ <dates>
>+ <discovery>2015-06-11</discovery>
>+ <entry>2015-07-11</entry>
>+ </dates>
>+ </vuln>
>+
>+ <vuln vid="ce658051-27ea-11e5-a4a5-002590263bf5">
>+ <topic>xen-kernel -- Information leak through XEN_DOMCTL_gettscinfo</topic>
>+ <affects>
>+ <package>
>+	<name>xen-kernel</name>
>+	<range><ge>4.0</ge><lt>4.5.0_3</lt></range>
>+ </package>
>+ </affects>
>+ <description>
>+ <body xmlns="http://www.w3.org/1999/xhtml">
>+	The Xen Project reports:
>+	<blockquote cite="http://xenbits.xen.org/xsa/advisory-132.html">
>+	 The handler for XEN_DOMCTL_gettscinfo failed to initialize a
>+	 padding field subsequently copied to guest memory.
>+	 A similar leak existed in XEN_SYSCTL_getdomaininfolist, which is
>+	 being addressed here regardless of that operation being declared
>+	 unsafe for disaggregation by XSA-77.
>+	 Malicious or buggy stub domain kernels or tool stacks otherwise
>+	 living outside of Domain0 may be able to read sensitive data
>+	 relating to the hypervisor or other guests not under the control of
>+	 that domain.
>+	</blockquote>
>+ </body>
>+ </description>
>+ <references>
>+ <cvename>CVE-2015-3340</cvename>
>+ <url>http://xenbits.xen.org/xsa/advisory-132.html</url>
>+ </references>
>+ <dates>
>+ <discovery>2015-04-20</discovery>
>+ <entry>2015-07-11</entry>
>+ </dates>
>+ </vuln>
>+
>+ <vuln vid="3d657340-27ea-11e5-a4a5-002590263bf5">
>+ <topic>xen-tools -- Unmediated PCI register access in qemu</topic>
>+ <affects>
>+ <package>
>+	<name>xen-tools</name>
>+	<range><ge>3.3</ge><lt>4.5.0_6</lt></range>
>+ </package>
>+ </affects>
>+ <description>
>+ <body xmlns="http://www.w3.org/1999/xhtml">
>+	The Xen Project reports:
>+	<blockquote cite="http://xenbits.xen.org/xsa/advisory-131.html">
>+	 Qemu allows guests to not only read, but also write all parts of
>+	 the PCI config space (but not extended config space) of passed
>+	 through PCI devices not explicitly dealt with for (partial)
>+	 emulation purposes.
>+	 Since the effect depends on the specific purpose of the the config
>+	 space field, it's not possbile to give a general statement about the
>+	 exact impact on the host or other guests. Privilege escalation,
>+	 host crash (Denial of Service), and leaked information all cannot be
>+	 excluded.
>+	</blockquote>
>+ </body>
>+ </description>
>+ <references>
>+ <cvename>CVE-2015-4106</cvename>
>+ <url>http://xenbits.xen.org/xsa/advisory-131.html</url>
>+ </references>
>+ <dates>
>+ <discovery>2015-06-02</discovery>
>+ <entry>2015-07-11</entry>
>+ </dates>
>+ </vuln>
>+
>+ <vuln vid="cbe1a0f9-27e9-11e5-a4a5-002590263bf5">
>+ <topic>xen-tools -- Guest triggerable qemu MSI-X pass-through error messages</topic>
>+ <affects>
>+ <package>
>+	<name>xen-tools</name>
>+	<range><ge>3.3</ge><lt>4.5.0_6</lt></range>
>+ </package>
>+ </affects>
>+ <description>
>+ <body xmlns="http://www.w3.org/1999/xhtml">
>+	The Xen Project reports:
>+	<blockquote cite="http://xenbits.xen.org/xsa/advisory-130.html">
>+	 Device model code dealing with guest PCI MSI-X interrupt management
>+	 activities logs messages on certain (supposedly) invalid guest
>+	 operations.
>+	 A buggy or malicious guest repeatedly invoking such operations may
>+	 result in the host disk to fill up, possibly leading to a Denial of
>+	 Service.
>+	</blockquote>
>+ </body>
>+ </description>
>+ <references>
>+ <cvename>CVE-2015-4105</cvename>
>+ <url>http://xenbits.xen.org/xsa/advisory-130.html</url>
>+ </references>
>+ <dates>
>+ <discovery>2015-06-02</discovery>
>+ <entry>2015-07-11</entry>
>+ </dates>
>+ </vuln>
>+
>+ <vuln vid="4db8a0f4-27e9-11e5-a4a5-002590263bf5">
>+ <topic>xen-tools -- PCI MSI mask bits inadvertently exposed to guests</topic>
>+ <affects>
>+ <package>
>+	<name>xen-tools</name>
>+	<range><ge>3.3</ge><lt>4.5.0_6</lt></range>
>+ </package>
>+ </affects>
>+ <description>
>+ <body xmlns="http://www.w3.org/1999/xhtml">
>+	The Xen Project reports:
>+	<blockquote cite="http://xenbits.xen.org/xsa/advisory-129.html">
>+	 The mask bits optionally available in the PCI MSI capability
>+	 structure are used by the hypervisor to occasionally suppress
>+	 interrupt delivery. Unprivileged guests were, however, nevertheless
>+	 allowed direct control of these bits.
>+	 Interrupts may be observed by Xen at unexpected times, which may
>+	 lead to a host crash and therefore a Denial of Service.
>+	</blockquote>
>+ </body>
>+ </description>
>+ <references>
>+ <cvename>CVE-2015-4104</cvename>
>+ <url>http://xenbits.xen.org/xsa/advisory-129.html</url>
>+ </references>
>+ <dates>
>+ <discovery>2015-06-02</discovery>
>+ <entry>2015-07-11</entry>
>+ </dates>
>+ </vuln>
>+
>+ <vuln vid="af38cfec-27e7-11e5-a4a5-002590263bf5">
>+ <topic>xen-tools -- Potential unintended writes to host MSI message data field via qemu</topic>
>+ <affects>
>+ <package>
>+	<name>xen-tools</name>
>+	<range><ge>3.3</ge><lt>4.5.0_6</lt></range>
>+ </package>
>+ </affects>
>+ <description>
>+ <body xmlns="http://www.w3.org/1999/xhtml">
>+	The Xen Project reports:
>+	<blockquote cite="http://xenbits.xen.org/xsa/advisory-128.html">
>+	 Logic is in place to avoid writes to certain host config space
>+	 fields when the guest must nevertheless be able to access their
>+	 virtual counterparts. A bug in how this logic deals with accesses
>+	 spanning multiple fields allows the guest to write to the host MSI
>+	 message data field.
>+	 While generally the writes write back the values previously read,
>+	 their value in config space may have got changed by the host between
>+	 the qemu read and write. In such a case host side interrupt handling
>+	 could become confused, possibly losing interrupts or allowing
>+	 spurious interrupt injection into other guests.
>+	 Certain untrusted guest administrators may be able to confuse host
>+	 side interrupt handling, leading to a Denial of Service.
>+	</blockquote>
>+ </body>
>+ </description>
>+ <references>
>+ <cvename>CVE-2015-4103</cvename>
>+ <url>http://xenbits.xen.org/xsa/advisory-128.html</url>
>+ </references>
>+ <dates>
>+ <discovery>2015-06-02</discovery>
>+ <entry>2015-07-11</entry>
>+ </dates>
>+ </vuln>
>+
>+ <vuln vid="103a47d5-27e7-11e5-a4a5-002590263bf5">
>+ <topic>xen-kernel -- Certain domctl operations may be abused to lock up the host</topic>
>+ <affects>
>+ <package>
>+	<name>xen-kernel</name>
>+	<range><ge>4.3</ge><lt>4.5.0_3</lt></range>
>+ </package>
>+ </affects>
>+ <description>
>+ <body xmlns="http://www.w3.org/1999/xhtml">
>+	The Xen Project reports:
>+	<blockquote cite="http://xenbits.xen.org/xsa/advisory-127.html">
>+	 XSA-77 put the majority of the domctl operations on a list
>+	 excepting them from having security advisories issued for them if
>+	 any effects their use might have could hamper security. Subsequently
>+	 some of them got declared disaggregation safe, but for a small
>+	 subset this was not really correct: Their (mis-)use may result in
>+	 host lockups.
>+	 As a result, the potential security benefits of toolstack
>+	 disaggregation are not always fully realised.
>+	 Domains deliberately given partial management control may be able
>+	 to deny service to the entire host.
>+	 As a result, in a system designed to enhance security by radically
>+	 disaggregating the management, the security may be reduced. But,
>+	 the security will be no worse than a non-disaggregated design.
>+	</blockquote>
>+ </body>
>+ </description>
>+ <references>
>+ <cvename>CVE-2015-2751</cvename>
>+ <url>http://xenbits.xen.org/xsa/advisory-127.html</url>
>+ </references>
>+ <dates>
>+ <discovery>2015-03-31</discovery>
>+ <entry>2015-07-11</entry>
>+ </dates>
>+ </vuln>
>+
>+ <vuln vid="79f401cd-27e6-11e5-a4a5-002590263bf5">
>+ <topic>xen-tools -- Unmediated PCI command register access in qemu</topic>
>+ <affects>
>+ <package>
>+	<name>xen-tools</name>
>+	<range><ge>3.3</ge><lt>4.5.0_6</lt></range>
>+ </package>
>+ </affects>
>+ <description>
>+ <body xmlns="http://www.w3.org/1999/xhtml">
>+	The Xen Project reports:
>+	<blockquote cite="http://xenbits.xen.org/xsa/advisory-126.html">
>+	 HVM guests are currently permitted to modify the memory and I/O
>+	 decode bits in the PCI command register of devices passed through to
>+	 them. Unless the device is an SR-IOV virtual function, after
>+	 disabling one or both of these bits subsequent accesses to the MMIO
>+	 or I/O port ranges would - on PCI Express devices - lead to
>+	 Unsupported Request responses. The treatment of such errors is
>+	 platform specific.
>+	 Furthermore (at least) devices under control of the Linux pciback
>+	 driver in the host are handed to guests with the aforementioned bits
>+	 turned off. This means that such accesses can similarly lead to
>+	 Unsupported Request responses until these flags are set as needed by
>+	 the guest.
>+	 In the event that the platform surfaces aforementioned UR responses
>+	 as Non-Maskable Interrupts, and either the OS is configured to treat
>+	 NMIs as fatal or (e.g. via ACPI's APEI) the platform tells the OS to
>+	 treat these errors as fatal, the host would crash, leading to a
>+	 Denial of Service.
>+	</blockquote>
>+ </body>
>+ </description>
>+ <references>
>+ <cvename>CVE-2015-2756</cvename>
>+ <url>http://xenbits.xen.org/xsa/advisory-126.html</url>
>+ </references>
>+ <dates>
>+ <discovery>2015-03-31</discovery>
>+ <entry>2015-07-11</entry>
>+ </dates>
>+ </vuln>
>+
>+ <vuln vid="d40c66cb-27e4-11e5-a4a5-002590263bf5">
>+ <topic>xen-kernel and xen-tools -- Long latency MMIO mapping operations are not preemptible</topic>
>+ <affects>
>+ <package>
>+	<name>xen-kernel</name>
>+	<range><lt>4.5.0_3</lt></range>
>+ </package>
>+ <package>
>+	<name>xen-tools</name>
>+	<range><lt>4.5.0_6</lt></range>
>+ </package>
>+ </affects>
>+ <description>
>+ <body xmlns="http://www.w3.org/1999/xhtml">
>+	The Xen Project reports:
>+	<blockquote cite="http://xenbits.xen.org/xsa/advisory-125.html">
>+	 The XEN_DOMCTL_memory_mapping hypercall allows long running
>+	 operations without implementing preemption.
>+	 This hypercall is used by the device model as part of the emulation
>+	 associated with configuration of PCI devices passed through to HVM
>+	 guests and is therefore indirectly exposed to those guests.
>+	 This can cause a physical CPU to become busy for a significant
>+	 period, leading to a host denial of service in some cases.
>+	 If a host denial of service is not triggered then it may instead be
>+	 possible to deny service to the domain running the device model,
>+	 e.g. domain 0.
>+	 This hypercall is also exposed more generally to all toolstacks.
>+	 However the uses of it in libxl based toolstacks are not believed
>+	 to open up any avenue of attack from an untrusted guest. Other
>+	 toolstacks may be vulnerable however.
>+	 The vulnerability is exposed via HVM guests which have a PCI device
>+	 assigned to them. A malicious HVM guest in such a configuration can
>+	 mount a denial of service attack affecting the whole system via its
>+	 associated device model (qemu-dm).
>+	 A guest is able to trigger this hypercall via operations which it
>+	 is legitimately expected to perform, therefore running the device
>+	 model as a stub domain does not offer protection against the host
>+	 denial of service issue. However it does offer some protection
>+	 against secondary issues such as denial of service against dom0.
>+	</blockquote>
>+ </body>
>+ </description>
>+ <references>
>+ <cvename>CVE-2015-2752</cvename>
>+ <url>http://xenbits.xen.org/xsa/advisory-125.html</url>
>+ </references>
>+ <dates>
>+ <discovery>2015-03-31</discovery>
>+ <entry>2015-07-11</entry>
>+ </dates>
>+ </vuln>
>+
>+ <vuln vid="83a28417-27e3-11e5-a4a5-002590263bf5">
>+ <topic>xen-kernel -- Hypervisor memory corruption due to x86 emulator flaw</topic>
>+ <affects>
>+ <package>
>+	<name>xen-kernel</name>
>+	<range><lt>4.5.0_3</lt></range>
>+ </package>
>+ </affects>
>+ <description>
>+ <body xmlns="http://www.w3.org/1999/xhtml">
>+	The Xen Project reports:
>+	<blockquote cite="http://xenbits.xen.org/xsa/advisory-123.html">
>+	 Instructions with register operands ignore eventual segment
>+	 overrides encoded for them. Due to an insufficiently conditional
>+	 assignment such a bogus segment override can, however, corrupt a
>+	 pointer used subsequently to store the result of the instruction.
>+	 A malicious guest might be able to read sensitive data relating to
>+	 other guests, or to cause denial of service on the host. Arbitrary
>+	 code execution, and therefore privilege escalation, cannot be
>+	 excluded.
>+	</blockquote>
>+ </body>
>+ </description>
>+ <references>
>+ <cvename>CVE-2015-2151</cvename>
>+ <url>http://xenbits.xen.org/xsa/advisory-123.html</url>
>+ </references>
>+ <dates>
>+ <discovery>2015-03-10</discovery>
>+ <entry>2015-07-11</entry>
>+ </dates>
>+ </vuln>
>+
>+ <vuln vid="ef9d041e-27e2-11e5-a4a5-002590263bf5">
>+ <topic>xen-kernel -- Information leak through version information hypercall</topic>
>+ <affects>
>+ <package>
>+	<name>xen-kernel</name>
>+	<range><lt>4.5.0_3</lt></range>
>+ </package>
>+ </affects>
>+ <description>
>+ <body xmlns="http://www.w3.org/1999/xhtml">
>+	The Xen Project reports:
>+	<blockquote cite="http://xenbits.xen.org/xsa/advisory-122.html">
>+	 The code handling certain sub-operations of the
>+	 HYPERVISOR_xen_version hypercall fails to fully initialize all
>+	 fields of structures subsequently copied back to guest memory. Due
>+	 to this hypervisor stack contents are copied into the destination of
>+	 the operation, thus becoming visible to the guest.
>+	 A malicious guest might be able to read sensitive data relating to
>+	 other guests.
>+	</blockquote>
>+ </body>
>+ </description>
>+ <references>
>+ <cvename>CVE-2015-2045</cvename>
>+ <url>http://xenbits.xen.org/xsa/advisory-122.html</url>
>+ </references>
>+ <dates>
>+ <discovery>2015-03-05</discovery>
>+ <entry>2015-07-11</entry>
>+ </dates>
>+ </vuln>
>+
>+ <vuln vid="5023f559-27e2-11e5-a4a5-002590263bf5">
>+ <topic>xen-kernel -- Information leak via internal x86 system device emulation</topic>
>+ <affects>
>+ <package>
>+	<name>xen-kernel</name>
>+	<range><lt>4.5.0_3</lt></range>
>+ </package>
>+ </affects>
>+ <description>
>+ <body xmlns="http://www.w3.org/1999/xhtml">
>+	The Xen Project reports:
>+	<blockquote cite="http://xenbits.xen.org/xsa/advisory-121.html">
>+	 Emulation routines in the hypervisor dealing with certain system
>+	 devices check whether the access size by the guest is a supported
>+	 one. When the access size is unsupported these routines failed to
>+	 set the data to be returned to the guest for read accesses, so that
>+	 hypervisor stack contents are copied into the destination of the
>+	 operation, thus becoming visible to the guest.
>+	 A malicious HVM guest might be able to read sensitive data relating
>+	 to other guests.
>+	</blockquote>
>+ </body>
>+ </description>
>+ <references>
>+ <cvename>CVE-2015-2044</cvename>
>+ <url>http://xenbits.xen.org/xsa/advisory-121.html</url>
>+ </references>
>+ <dates>
>+ <discovery>2015-03-05</discovery>
>+ <entry>2015-07-11</entry>
>+ </dates>
>+ </vuln>
>+
>+ <vuln vid="0d732fd1-27e0-11e5-a4a5-002590263bf5">
>+ <topic>xen-tools -- HVM qemu unexpectedly enabling emulated VGA graphics backends</topic>
>+ <affects>
>+ <package>
>+	<name>xen-tools</name>
>+	<range><lt>4.5.0_6</lt></range>
>+ </package>
>+ </affects>
>+ <description>
>+ <body xmlns="http://www.w3.org/1999/xhtml">
>+	The Xen Project reports:
>+	<blockquote cite="http://xenbits.xen.org/xsa/advisory-119.html">
>+	 When instantiating an emulated VGA device for an x86 HVM guest qemu
>+	 will by default enable a backend to expose that device, either SDL
>+	 or VNC depending on the version of qemu and the build time
>+	 configuration.
>+	 The libxl toolstack library does not explicitly disable these
>+	 default backends when they are not enabled, leading to an unexpected
>+	 backend running.
>+	 If either SDL or VNC is explicitly enabled in the guest
>+	 configuration then only the expected backends will be enabled.
>+	 This affects qemu-xen and qemu-xen-traditional differently.
>+	 If qemu-xen was compiled with SDL support then this would result in
>+	 an SDL window being opened if $DISPLAY is valid, or a failure to
>+	 start the guest if not.
>+	 If qemu-xen was compiled without SDL support then qemu would
>+	 instead start a VNC server listening on ::1 (IPv6 localhost) or
>+	 127.0.0.1 (IPv4 localhost) with IPv6 preferred if available. A VNC
>+	 password will not be configured even if one is present in the guest
>+	 configuration.
>+	 qemu-xen-traditional will never start a vnc backend unless
>+	 explicitly configured. However by default it will start an SDL
>+	 backend if it was built with SDL support and $DISPLAY is valid.
>+	</blockquote>
>+ </body>
>+ </description>
>+ <references>
>+ <cvename>CVE-2015-2152</cvename>
>+ <url>http://xenbits.xen.org/xsa/advisory-119.html</url>
>+ </references>
>+ <dates>
>+ <discovery>2015-03-13</discovery>
>+ <entry>2015-07-11</entry>
>+ </dates>
>+ </vuln>
>+
>+ <vuln vid="912cb7f7-27df-11e5-a4a5-002590263bf5">
>+ <topic>xen-kernel -- arm: vgic: incorrect rate limiting of guest triggered logging</topic>
>+ <affects>
>+ <package>
>+	<name>xen-kernel</name>
>+	<range><ge>4.4</ge><lt>4.5.0_3</lt></range>
>+ </package>
>+ </affects>
>+ <description>
>+ <body xmlns="http://www.w3.org/1999/xhtml">
>+	The Xen Project reports:
>+	<blockquote cite="http://xenbits.xen.org/xsa/advisory-118.html">
>+	 On ARM systems the code which deals with virtualising the GIC
>+	 distributor would, under various circumstances, log messages on a
>+	 guest accessible code path without appropriate rate limiting.
>+	 A malicious guest could cause repeated logging to the hypervisor
>+	 console, leading to a Denial of Service attack.
>+	</blockquote>
>+ </body>
>+ </description>
>+ <references>
>+ <cvename>CVE-2015-1563</cvename>
>+ <url>http://xenbits.xen.org/xsa/advisory-118.html</url>
>+ </references>
>+ <dates>
>+ <discovery>2015-01-29</discovery>
>+ <entry>2015-07-11</entry>
>+ </dates>
>+ </vuln>
>+
>+ <vuln vid="785c86b1-27d6-11e5-a4a5-002590263bf5">
>+ <topic>xen-kernel -- arm: vgic-v2: GICD_SGIR is not properly emulated</topic>
>+ <affects>
>+ <package>
>+	<name>xen-kernel</name>
>+	<range><ge>4.5</ge><lt>4.5.0_3</lt></range>
>+ </package>
>+ </affects>
>+ <description>
>+ <body xmlns="http://www.w3.org/1999/xhtml">
>+	The Xen Project reports:
>+	<blockquote cite="http://xenbits.xen.org/xsa/advisory-117.html">
>+	 When decoding a guest write to a specific register in the virtual
>+	 interrupt controller Xen would treat an invalid value as a critical
>+	 error and crash the host.
>+	 By writing an invalid value to the GICD.SGIR register a guest can
>+	 crash the host, resulting in a Denial of Service attack.
>+	</blockquote>
>+ </body>
>+ </description>
>+ <references>
>+ <cvename>CVE-2015-0268</cvename>
>+ <url>http://xenbits.xen.org/xsa/advisory-117.html</url>
>+ </references>
>+ <dates>
>+ <discovery>2015-02-12</discovery>
>+ <entry>2015-07-11</entry>
>+ </dates>
>+ </vuln>
>+
> <vuln vid="7313b0e3-27b4-11e5-a15a-50af736ef1c0">
> <topic>pivotx -- Multiple unrestricted file upload vulnerabilities</topic>
> <affects>

Actions: View | Diff

Attachments on bug 201416: 158521 | 158522 | 158621 | 158622