Date: Wed, 11 Nov 2015 03:22:07 +0000 (UTC) From: Jason Unovitch <junovitch@FreeBSD.org> To: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: svn commit: r401224 - head/security/vuxml Message-ID: <201511110322.tAB3M7HR033610@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: junovitch Date: Wed Nov 11 03:22:07 2015 New Revision: 401224 URL: https://svnweb.freebsd.org/changeset/ports/401224 Log: Document Xen XSAs-{142,148,149,150,151,152,153} Security: CVE-2015-7311 Security: CVE-2015-7835 Security: CVE-2015-7969 Security: CVE-2015-7970 Security: CVE-2015-7971 Security: CVE-2015-7972 Security: https://vuxml.FreeBSD.org/freebsd/301b04d7-881c-11e5-ab94-002590263bf5.html Security: https://vuxml.FreeBSD.org/freebsd/3d9f6260-881d-11e5-ab94-002590263bf5.html Security: https://vuxml.FreeBSD.org/freebsd/83350009-881e-11e5-ab94-002590263bf5.html Security: https://vuxml.FreeBSD.org/freebsd/c0e76d33-8821-11e5-ab94-002590263bf5.html Security: https://vuxml.FreeBSD.org/freebsd/e3792855-881f-11e5-ab94-002590263bf5.html Security: https://vuxml.FreeBSD.org/freebsd/e4848ca4-8820-11e5-ab94-002590263bf5.html Security: https://vuxml.FreeBSD.org/freebsd/fc1f8795-881d-11e5-ab94-002590263bf5.html Modified: head/security/vuxml/vuln.xml Modified: head/security/vuxml/vuln.xml ============================================================================== --- head/security/vuxml/vuln.xml Wed Nov 11 02:16:23 2015 (r401223) +++ head/security/vuxml/vuln.xml Wed Nov 11 03:22:07 2015 (r401224) @@ -58,6 +58,247 @@ Notes: --> <vuxml xmlns="http://www.vuxml.org/apps/vuxml-1">; + <vuln vid="c0e76d33-8821-11e5-ab94-002590263bf5"> + <topic>xen-tools -- populate-on-demand balloon size inaccuracy can crash guests</topic> + <affects> + <package> + <name>xen-tools</name> + <range><ge>3.4</ge><lt>4.5.1_2</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <p>The Xen Project reports:</p> + <blockquote cite="http://xenbits.xen.org/xsa/advisory-153.html">; + <p>Guests configured with PoD might be unstable, especially under + load. In an affected guest, an unprivileged guest user might be + able to cause a guest crash, perhaps simply by applying load so + as to cause heavy memory pressure within the guest.</p> + </blockquote> + </body> + </description> + <references> + <cvename>CVE-2015-7972</cvename> + <url>http://xenbits.xen.org/xsa/advisory-153.html</url>; + </references> + <dates> + <discovery>2015-10-29</discovery> + <entry>2015-11-11</entry> + </dates> + </vuln> + + <vuln vid="e4848ca4-8820-11e5-ab94-002590263bf5"> + <topic>xen-kernel -- some pmu and profiling hypercalls log without rate limiting</topic> + <affects> + <package> + <name>xen-kernel</name> + <range><ge>3.2</ge><lt>4.5.1_1</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <p>The Xen Project reports:</p> + <blockquote cite="http://xenbits.xen.org/xsa/advisory-152.html">; + <p>HYPERCALL_xenoprof_op and HYPERVISOR_xenpmu_op log some errors and + attempts at invalid operations. These log messages are not + rate-limited, even though they can be triggered by guests.</p> + <p>A malicious guest could cause repeated logging to the hypervisor + console, leading to a Denial of Service attack.</p> + </blockquote> + </body> + </description> + <references> + <cvename>CVE-2015-7971</cvename> + <url>http://xenbits.xen.org/xsa/advisory-152.html</url>; + </references> + <dates> + <discovery>2015-10-29</discovery> + <entry>2015-11-11</entry> + </dates> + </vuln> + + <vuln vid="e3792855-881f-11e5-ab94-002590263bf5"> + <topic>xen-kernel -- leak of per-domain profiling-related vcpu pointer array</topic> + <affects> + <package> + <name>xen-kernel</name> + <range><ge>4.0</ge><lt>4.5.1_1</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <p>The Xen Project reports:</p> + <blockquote cite="http://xenbits.xen.org/xsa/advisory-151.html">; + <p>A domain's xenoprofile state contains an array of per-vcpu + information... This array is leaked on domain teardown. This memory + leak could -- over time -- exhaust the host's memory.</p> + <p>The following parties can mount a denial of service attack + affecting the whole system:</p> + <ul> + <li>A malicious guest administrator via XENOPROF_get_buffer.</li> + <li>A domain given suitable privilege over another domain via + XENOPROF_set_passive (this would usually be a domain being + used to profile another domain, eg with the xenoprof tool).</li> + </ul> + <p>The ability to also restart or create suitable domains is also + required to fully exploit the issue. Without this the leak is + limited to a small multiple of the maximum number of vcpus for the + domain.</p> + </blockquote> + </body> + </description> + <references> + <cvename>CVE-2015-7969</cvename> + <url>http://xenbits.xen.org/xsa/advisory-151.html</url>; + </references> + <dates> + <discovery>2015-10-29</discovery> + <entry>2015-11-11</entry> + </dates> + </vuln> + + <vuln vid="83350009-881e-11e5-ab94-002590263bf5"> + <topic>xen-kernel -- Long latency populate-on-demand operation is not preemptible</topic> + <affects> + <package> + <name>xen-kernel</name> + <range><ge>3.4</ge><lt>4.5.1_1</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <p>The Xen Project reports:</p> + <blockquote cite="http://xenbits.xen.org/xsa/advisory-150.html">; + <p>When running an HVM domain in Populate-on-Demand mode, Xen would + sometimes search the domain for memory to reclaim, in response to + demands for population of other pages in the same domain. This + search runs without preemption. The guest can, by suitable + arrangement of its memory contents, create a situation where this + search is a time-consuming linear scan of the guest's address + space.</p> + <p>A malicious HVM guest administrator can cause a denial of service. + Specifically, prevent use of a physical CPU for a significant + period.</p> + </blockquote> + </body> + </description> + <references> + <cvename>CVE-2015-7970</cvename> + <url>http://xenbits.xen.org/xsa/advisory-150.html</url>; + </references> + <dates> + <discovery>2015-10-29</discovery> + <entry>2015-11-11</entry> + </dates> + </vuln> + + <vuln vid="fc1f8795-881d-11e5-ab94-002590263bf5"> + <topic>xen-kernel -- leak of main per-domain vcpu pointer array</topic> + <affects> + <package> + <name>xen-kernel</name> + <range><lt>4.5.1_1</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <p>The Xen Project reports:</p> + <blockquote cite="http://xenbits.xen.org/xsa/advisory-149.html">; + <p>A domain's primary array of vcpu pointers can be allocated by a + toolstack exactly once in the lifetime of a domain via the + XEN_DOMCTL_max_vcpus hypercall. This array is leaked on domain + teardown. This memory leak could -- over time -- exhaust the host's + memory.</p> + <p>A domain given partial management control via XEN_DOMCTL_max_vcpus + can mount a denial of service attack affecting the whole system. The + ability to also restart or create suitable domains is also required + to fully exploit the issue. Without this the leak is limited to a + small multiple of the maximum number of vcpus for the domain. The + maximum leak is 64kbytes per domain (re)boot (less on ARM).</p> + </blockquote> + </body> + </description> + <references> + <cvename>CVE-2015-7969</cvename> + <url>http://xenbits.xen.org/xsa/advisory-149.html</url>; + </references> + <dates> + <discovery>2015-10-29</discovery> + <entry>2015-11-11</entry> + </dates> + </vuln> + + <vuln vid="3d9f6260-881d-11e5-ab94-002590263bf5"> + <topic>xen-kernel -- Uncontrolled creation of large page mappings by PV guests</topic> + <affects> + <package> + <name>xen-kernel</name> + <range><ge>3.4</ge><lt>4.5.1_1</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <p>The Xen Project reports:</p> + <blockquote cite="http://xenbits.xen.org/xsa/advisory-148.html">; + <p>The code to validate level 2 page table entries is bypassed when + certain conditions are satisfied. This means that a PV guest can + create writeable mappings using super page mappings. Such writeable + mappings can violate Xen intended invariants for pages which Xen is + supposed to keep read-only. This is possible even if the + "allowsuperpage" command line option is not used.</p> + <p>Malicious PV guest administrators can escalate privilege so as to + control the whole system.</p> + </blockquote> + </body> + </description> + <references> + <cvename>CVE-2015-7835</cvename> + <url>http://xenbits.xen.org/xsa/advisory-148.html</url>; + </references> + <dates> + <discovery>2015-10-29</discovery> + <entry>2015-11-11</entry> + </dates> + </vuln> + + <vuln vid="301b04d7-881c-11e5-ab94-002590263bf5"> + <topic>xen-tools -- libxl fails to honour readonly flag on disks with qemu-xen</topic> + <affects> + <package> + <name>xen-tools</name> + <range><ge>4.1</ge><lt>4.5.1_1</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml">; + <p>The Xen Project reports:</p> + <blockquote cite="http://xenbits.xen.org/xsa/advisory-142.html">; + <p>Callers of libxl can specify that a disk should be read-only to the + guest. However, there is no code in libxl to pass this information + to qemu-xen (the upstream-based qemu); and indeed there is no way in + qemu to make a disk read-only.</p> + <p>The vulnerability is exploitable only via devices emulated by the + device model, not the parallel PV devices for supporting PVHVM. + Normally the PVHVM device unplug protocol renders the emulated + devices inaccessible early in boot.</p> + <p>Malicious guest administrators or (in some situations) users may be + able to write to supposedly read-only disk images.</p> + <p>CDROM devices (that is, devices specified to be presented to the + guest as CDROMs, regardless of the nature of the backing storage on + the host) are not affected.</p> + </blockquote> + </body> + </description> + <references> + <cvename>CVE-2015-7311</cvename> + <url>http://xenbits.xen.org/xsa/advisory-142.html</url>; + </references> + <dates> + <discovery>2015-09-22</discovery> + <entry>2015-11-11</entry> + </dates> + </vuln> + <vuln vid="2f7f4db2-8819-11e5-ab94-002590263bf5"> <topic>p5-HTML-Scrubber -- XSS vulnerability</topic> <affects>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201511110322.tAB3M7HR033610>