xen: Multiple security issues (CVE-2015-5166, CVE-2015-5165, CVE-2015-6654, CVE-2015-7311, CVE-2015-7835, CVE-2015-7969, CVE-2015-7970, CVE-2015-7971, CVE-2015-7972) )
(CVE-2015-5166, xsa-139) Use after free in QEMU/Xen block unplug protocol
When unplugging an emulated block device the device was not fully
unplugged, meaning a second unplug attempt would attempt to unplug the
device a second time using a previously freed pointer.
References:
http://xenbits.xen.org/xsa/advisory-139.html
(CVE-2015-5165, xsa-140) QEMU leak of uninitialized heap memory in rtl8139 device model
The QEMU model of the RTL8139 network card did not sufficiently
validate inputs in the C+ mode offload emulation. This results in
uninitialised memory from the QEMU process’s heap being leaked to the
domain as well as to the network.
References:
http://xenbits.xen.org/xsa/advisory-140.html
(CVE-2015-6654, xsa-141) printk is not rate-limited in xenmem_add_to_physmap_one
XENMAPSPACE_gmfn_foreign dumps the p2m, on ARM, when it fails to get
a
reference on the foreign page. However, dump_p2m_lookup does not use
rate-limited printk.
A malicious infrastructure domain, which is allowed to map memory of
a foreign guest, would be able to flood the Xen console.
References:
http://xenbits.xen.org/xsa/advisory-141.html
(CVE-2015-7311, xsa-142) libxl fails to honour readonly flag on disks with qemu-xen
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.
References:
http://xenbits.xen.org/xsa/advisory-142.html
(CVE-2015-7835, XSA-148) x86: Uncontrolled creation of large page mappings by PV guests
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.
References:
http://xenbits.xen.org/xsa/advisory-148.html
(CVE-2015-7969, XSA-149) leak of main per-domain vcpu pointer array
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.
References:
http://xenbits.xen.org/xsa/advisory-149.html
(CVE-2015-7970, XSA-150) x86: Long latency populate-on-demand operation is not preemptible
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.
The scan might be triggered by the guest’s own actions, or by
toolstack operations such as migration. In guests affected by
XSA-153, this scan might be triggered simply by memory pressure in the
guest.
References:
http://xenbits.xen.org/xsa/advisory-150.html
(CVE-2015-7969, XSA-151) x86: leak of per-domain profiling-related vcpu pointer array
A domain’s xenoprofile state contains an array of per-vcpu
information, which is allocated once in the lifetime of a domain in
response to that domain using the XENOPROF_get_buffer hypercall on
itself or by a domain with the privilege to profile a target domain
using the XENOPROF_set_passive hypercall.
This array is leaked on domain teardown. This memory leak could —
over time — exhaust the host’s memory.
References:
http://xenbits.xen.org/xsa/advisory-151.html
(CVE-2015-7971, XSA-152) x86: some pmu and profiling hypercalls log without rate limiting
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.
References:
http://xenbits.xen.org/xsa/advisory-152.html
(CVE-2015-7972, XSA-153) x86: populate-on-demand balloon size inaccuracy can crash guests
The design of the memory populate-on-demand (PoD) system requires that
a guest’s memory ballooning driver reach its memory reduction target.
The target is not entirely well-defined in terms of the information
visible to the appropriate parts of the system, so some unknown set of
guests (but probably most guests) will fail this criterion.
If the guest memory balloon driver does not free sufficient memory to
reach its target, the guest will proceed to run with a nonzero number
of outstanding PoD pages. When the guest or management toolstack
touches such a page, the hypervisor would search the guest memory for
a page containing only zeroes.
If no such page is found, the guest crashes. Prior to the patch for
XSA-150, the search might lock up the relevant physical cpu for a
while. After the patch to XSA-150, it might crash the guest even if a
suitable zero page is available.
This means that in the current arrangements toolstack software must
apply an adjustment to a guest’s PoD target as supplied to Xen.
Neither xend nor libxl do this.
References:
http://xenbits.xen.org/xsa/advisory-153.html
(from redmine: issue id 4744, created on 2015-10-07, closed on 2015-12-04)
- Relations:
- child #4745 (closed)
- child #4746 (closed)
- child #4747 (closed)
- child #4748 (closed)
- child #4749 (closed)