nixpkgs/pkgs/applications/virtualization
Michał Pałka 7b5d72ce04 xen: patch for XSAs: 216, 217, 218, 219, 220, 221, 222, and 224 (xen 4.8)
This commit contains security patches for xen 4.8. The patches
for XSA-216 applied to the kernel are omitted, as they are part of
80e0cda7ff.

XSA-216 Issue Description:

> The block interface response structure has some discontiguous fields.
> Certain backends populate the structure fields of an otherwise
> uninitialized instance of this structure on their stacks, leaking
> data through the (internal or trailing) padding field.

More: https://xenbits.xen.org/xsa/advisory-216.html

XSA-217 Issue Description:

> Domains controlling other domains are permitted to map pages owned by
> the domain being controlled.  If the controlling domain unmaps such a
> page without flushing the TLB, and if soon after the domain being
> controlled transfers this page to another PV domain (via
> GNTTABOP_transfer or, indirectly, XENMEM_exchange), and that third
> domain uses the page as a page table, the controlling domain will have
> write access to a live page table until the applicable TLB entry is
> flushed or evicted.  Note that the domain being controlled is
> necessarily HVM, while the controlling domain is PV.

More: https://xenbits.xen.org/xsa/advisory-217.html

XSA-218 Issue Description:

> We have discovered two bugs in the code unmapping grant references.
>
> * When a grant had been mapped twice by a backend domain, and then
> unmapped by two concurrent unmap calls, the frontend may be informed
> that the page had no further mappings when the first call completed rather
> than when the second call completed.
>
> * A race triggerable by an unprivileged guest could cause a grant
> maptrack entry for grants to be "freed" twice.  The ultimate effect of
> this would be for maptrack entries for a single domain to be re-used.

More: https://xenbits.xen.org/xsa/advisory-218.html

XSA-219 Issue Description:

> When using shadow paging, writes to guest pagetables must be trapped and
> emulated, so the shadows can be suitably adjusted as well.
>
> When emulating the write, Xen maps the guests pagetable(s) to make the final
> adjustment and leave the guest's view of its state consistent.
>
> However, when mapping the frame, Xen drops the page reference before
> performing the write.  This is a race window where the underlying frame can
> change ownership.
>
> One possible attack scenario is for the frame to change ownership and to be
> inserted into a PV guest's pagetables.  At that point, the emulated write will
> be an unaudited modification to the PV pagetables whose value is under guest
> control.

More: https://xenbits.xen.org/xsa/advisory-219.html

XSA-220 Issue Description:

> Memory Protection Extensions (MPX) and Protection Key (PKU) are features in
> newer processors, whose state is intended to be per-thread and context
> switched along with all other XSAVE state.
>
> Xen's vCPU context switch code would save and restore the state only
> if the guest had set the relevant XSTATE enable bits.  However,
> surprisingly, the use of these features is not dependent (PKU) or may
> not be dependent (MPX) on having the relevant XSTATE bits enabled.
>
> VMs which use MPX or PKU, and context switch the state manually rather
> than via XSAVE, will have the state leak between vCPUs (possibly,
> between vCPUs in different guests).  This in turn corrupts state in
> the destination vCPU, and hence may lead to weakened protections
>
> Experimentally, MPX appears not to make any interaction with BND*
> state if BNDCFGS.EN is set but XCR0.BND{CSR,REGS} are clear.  However,
> the SDM is not clear in this case; therefore MPX is included in this
> advisory as a precaution.

More: https://xenbits.xen.org/xsa/advisory-220.html

XSA-221 Issue Description:

> When polling event channels, in general arbitrary port numbers can be
> specified.  Specifically, there is no requirement that a polled event
> channel ports has ever been created.  When the code was generalised
> from an earlier implementation, introducing some intermediate
> pointers, a check should have been made that these intermediate
> pointers are non-NULL.  However, that check was omitted.

More: https://xenbits.xen.org/xsa/advisory-221.html

XSA-222 Issue Description:

> Certain actions require removing pages from a guest's P2M
> (Physical-to-Machine) mapping.  When large pages are in use to map
> guest pages in the 2nd-stage page tables, such a removal operation may
> incur a memory allocation (to replace a large mapping with individual
> smaller ones).  If this allocation fails, these errors are ignored by
> the callers, which would then continue and (for example) free the
> referenced page for reuse.  This leaves the guest with a mapping to a
> page it shouldn't have access to.
>
> The allocation involved comes from a separate pool of memory created
> when the domain is created; under normal operating conditions it never
> fails, but a malicious guest may be able to engineer situations where
> this pool is exhausted.

More: https://xenbits.xen.org/xsa/advisory-222.html

XSA-224 Issue Description:

> We have discovered a number of bugs in the code mapping and unmapping
> grant references.
>
> * If a grant is mapped with both the GNTMAP_device_map and
> GNTMAP_host_map flags, but unmapped only with host_map, the device_map
> portion remains but the page reference counts are lowered as though it
> had been removed. This bug can be leveraged cause a page's reference
> counts and type counts to fall to zero while retaining writeable
> mappings to the page.
>
> * Under some specific conditions, if a grant is mapped with both the
> GNTMAP_device_map and GNTMAP_host_map flags, the operation may not
> grab sufficient type counts.  When the grant is then unmapped, the
> type count will be erroneously reduced.  This bug can be leveraged
> cause a page's reference counts and type counts to fall to zero while
> retaining writeable mappings to the page.
>
> * When a grant reference is given to an MMIO region (as opposed to a
> normal guest page), if the grant is mapped with only the
> GNTMAP_device_map flag set, a mapping is created at host_addr anyway.
> This does *not* cause reference counts to change, but there will be no
> record of this mapping, so it will not be considered when reporting
> whether the grant is still in use.

More: https://xenbits.xen.org/xsa/advisory-224.html
2017-06-27 12:02:59 +00:00
..
8086tiny
aqemu aqemu: init at 0.9.2 2017-02-10 12:48:29 +01:00
bochs treewide: explicitly specify gtk and related package versions 2016-09-12 18:26:06 +03:00
cbfstool cbfstool: git-2015-07-09 -> 4.5 2016-10-22 21:07:33 +03:00
containerd containerd: use removeReferencesTo 2017-03-11 15:17:32 +01:00
docker docker-proxy: remove go references 2017-05-17 22:14:34 +01:00
docker-distribution docker-distribution: 2.5.1 -> 2.6.0 2017-04-04 21:01:27 -04:00
driver
ecs-agent ecs-agent: init at 1.14.0 2017-02-10 04:33:48 +00:00
lkl lkl: split outputs 2017-05-24 01:07:26 +02:00
open-vm-tools open-vm-tools: fixup build with glibc-2.25 2017-02-22 16:54:07 +01:00
openstack Python: replace requests2 with requests tree-wide 2017-05-07 12:56:09 +02:00
OVMF OVMF: fix build 2017-05-29 12:21:17 +02:00
qboot
qemu qemu: 2.8.1 -> 2.9.0 2017-04-23 14:20:48 +02:00
rancher-compose rancher-compose: set version during build 2016-10-22 14:40:30 +02:00
remotebox remotebox: 2.1 -> 2.2 2016-11-09 02:24:46 +01:00
rkt rkt: 1.25.0 -> 1.26.0 2017-05-25 18:13:54 -04:00
runc Update runc to 1.0.0-rc3 2017-06-10 18:05:57 +02:00
seabios Merge remote-tracking branch 'upstream/master' into hardened-stdenv 2016-08-03 13:34:44 +00:00
singularity singularity: init 2.2 2016-11-15 09:11:53 +11:00
spice-vdagent spice-vdagent: 0.16.0 -> 0.17.0 2016-09-26 08:20:04 -04:00
tini docker: 1.12.6 -> 1.13.0 2017-01-18 21:33:37 +01:00
virt-manager virtmanager-qt: 0.43.70.2 -> 0.43.72 2017-06-19 19:26:19 +08:00
virt-top virt-top: init at 1.0.8 (#21536) 2017-02-04 16:07:45 +01:00
virt-viewer libvirt packages: fix & clean up dependencies 2017-03-28 19:45:01 +02:00
virtinst virtinst: do not depend on glanceclient 2017-05-07 10:02:33 +02:00
virtualbox virtualbox: Rebase hardened.patch on top of 5.1.22 2017-06-23 05:48:54 +02:00
xen xen: patch for XSAs: 216, 217, 218, 219, 220, 221, 222, and 224 (xen 4.8) 2017-06-27 12:02:59 +00:00
xhyve xhyve: update and fix to use our Hypervisor framework 2017-03-14 22:38:35 -04:00