From oraclevm-errata at oss.oracle.com Wed Jul 27 11:49:46 2016 From: oraclevm-errata at oss.oracle.com (Errata Announcements for Oracle VM) Date: Wed, 27 Jul 2016 11:49:46 -0700 Subject: [Oraclevm-errata] OVMSA-2016-0088 Important: Oracle VM 3.4 xen security update Message-ID: <5799024A.2010108@oracle.com> Oracle VM Security Advisory OVMSA-2016-0088 The following updated rpms for Oracle VM 3.4 have been uploaded to the Unbreakable Linux Network: x86_64: xen-4.4.4-75.0.1.el6.x86_64.rpm xen-tools-4.4.4-75.0.1.el6.x86_64.rpm SRPMS: http://oss.oracle.com/oraclevm/server/3.4/SRPMS-updates/xen-4.4.4-75.0.1.el6.src.rpm Description of changes: [4.4.4-75.0.1.el6] - BUILDINFO: commit=aff08b43b1a504aa14a0fce65302ccf515b69fdf - Remove unsafe bits from the mod_l?_entry() fastpath (Andrew Cooper) {CVE-2016-6258} - x86/mm: fully honor PS bits in guest page table walks (Jan Beulich) {CVE-2016-4480} {CVE-2016-4480} - libxl: Document ~/serial/ correctly (Ian Jackson) {CVE-2016-4962} - libxl: Cleanup: Have libxl__alloc_vdev use /libxl (Ian Jackson) {CVE-2016-4962} - libxl: Do not trust frontend for nic in getinfo (Ian Jackson) {CVE-2016-4962} - libxl: Do not trust frontend for nic in libxl_devid_to_device_nic (Ian Jackson) {CVE-2016-4962} - libxl: Do not trust frontend for vtpm in getinfo (Ian Jackson) {CVE-2016-4962} - libxl: Do not trust frontend for vtpm list (Ian Jackson) {CVE-2016-4962} - libxl: Do not trust frontend for disk in getinfo (Ian Jackson) {CVE-2016-4962} - libxl: Do not trust frontend for disk eject event (Ian Jackson) {CVE-2016-4962} - libxl: Do not trust frontend in libxl__device_nextid (Ian Jackson) {CVE-2016-4962} - libxl: Do not trust frontend in libxl__devices_destroy (Ian Jackson) {CVE-2016-4962} - libxl: Provide libxl__backendpath_parse_domid (Ian Jackson) {CVE-2016-4962} - libxl: Record backend/frontend paths in /libxl/$DOMID (Ian Jackson) {CVE-2016-4962} - x86: limit GFNs to 32 bits for shadowed superpages. (Tim Deegan) {CVE-2016-3960} - x86: fix information leak on AMD CPUs (Jan Beulich) {CVE-2016-3158} {CVE-2016-3159} {CVE-2016-3158} {CVE-2016-3159} {CVE-2016-3158} {CVE-2016-3159} - x86: enforce consistent cachability of MMIO mappings (Jan Beulich) {CVE-2016-2270} {CVE-2016-2270} From oraclevm-errata at oss.oracle.com Wed Jul 27 12:19:47 2016 From: oraclevm-errata at oss.oracle.com (Errata Announcements for Oracle VM) Date: Wed, 27 Jul 2016 12:19:47 -0700 Subject: [Oraclevm-errata] OVMSA-2016-0089 Important: Oracle VM 3.3 xen security update Message-ID: <57990953.3090304@oracle.com> Oracle VM Security Advisory OVMSA-2016-0089 The following updated rpms for Oracle VM 3.3 have been uploaded to the Unbreakable Linux Network: x86_64: xen-4.3.0-55.el6.119.49.x86_64.rpm xen-tools-4.3.0-55.el6.119.49.x86_64.rpm SRPMS: http://oss.oracle.com/oraclevm/server/3.3/SRPMS-updates/xen-4.3.0-55.el6.119.49.src.rpm Description of changes: [4.3.0-55.el6.119.49] - x86/HVM: correct CPUID leaf 80000008 handling - 6c733e54 xsa173_01_0001-x86-HVM-correct-CPUID-leaf-80000008-handling.patch was based on upstream commit: ef437690af8b75e6758dce77af75a22b63982883 x86/HVM: correct CPUID leaf 80000008 handling It should have been based on upstream commit: 6c733e549889a9b8c4e03140348b8e00241d4ce9 x86/HVM: correct CPUID leaf 80000008 handling The changes in this patch are the differences between those two patches. Signed-off-by: Chuck Anderson Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Boris Ostrovsky [bug 24351970] [4.3.0-55.el6.119.48] - x86: fix unintended fallthrough case from XSA-154 ... and annotate the other deliberate one: Coverity objects otherwise. Signed-off-by: Andrew Cooper One of the two instances was actually a bug. Signed-off-by: Jan Beulich master commit: 8dd6d1c099865ee5f5916616a0ca79cd943c46f9 master date: 2016-02-18 15:10:07 +0100 Upstream commit ccc7adf9cff5d5f93720afcc1d0f7227d50feab2 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky Reviewed-by: Chuck Anderson [bug 22752939] {CVE-2016-2270} [4.3.0-55.el6.119.47] - x86/pv: Remove unsafe bits from the mod_l?_entry() fastpath All changes in writeability and cacheability must go through full re-validation. Rework the logic as a whitelist, to make it clearer to follow. This is XSA-182 Signed-off-by: Andrew Cooper Reviewed-by: Tim Deegan Upstream commit 798c1498f764bfaa7b0b955bab40b01b0610d372 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 24307891] [4.3.0-55.el6.119.46] - libxl: Do not trust frontend for nic in getinfo libxl_device_nic_getinfo needs to examine devices without trusting frontend-controlled data. So: * Use /libxl to find the backend path. * Parse the backend path to find the backend domid, rather than reading it from the frontend. This is part of XSA-175. Signed-off-by: Ian Jackson Reviewed-by: Wei Liu Upstream commit 5811d6bdf5bb6e80db7acaf8bab196f9476f5164 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23530771] {CVE-2016-4962} [4.3.0-55.el6.119.45] - -bxl: Do not trust frontend for nic in libxl_devid_to_device_nic Find the backend by reading the pointer in /libxl rather than in the guest's frontend area. This is part of XSA-175. Signed-off-by: Ian Jackson Reviewed-by: Wei Liu Upstream commit 2c74b8dd4c5d6982eee1fd852f9aa10ec1b24545 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky -This line, and those below, will be ignored-- ? 0003-libxl-Do-not-trust-frontend-in-libxl__devices_destro.patch ? .0009-libxl-Do-not-trust-frontend-for-nic-in-libxl_devid_t.patch.swp ? 0001-libxl-Record-backend-frontend-paths-in-libxl-DOMID.patch ? 0004-libxl-Do-not-trust-frontend-in-libxl__device_nextid.patch ? 0007-libxl-Do-not-trust-frontend-for-vtpm-list.patch ? 0005-libxl-Do-not-trust-frontend-for-disk-eject-event.patch ? xsa176.patch ? 0008-libxl-Do-not-trust-frontend-for-vtpm-in-getinfo.patch ? 0009-libxl-Do-not-trust-frontend-for-nic-in-libxl_devid_t.patch ? 0002-libxl-Provide-libxl__backendpath_parse_domid.patch ? 0006-libxl-Do-not-trust-frontend-for-disk-in-getinfo.patch ? 0001-x86-mm-Handle-1GiB-superpages-in-the-pagetable-walke.patch ? 0007-libxl-Do-not-trust-frontend-for-vtpm-list.patch.1 ? 0010-libxl-Do-not-trust-frontend-for-nic-in-getinfo.patch ? xsa180-qemut.patch ? xsa180-qemuu.patch ? tools/qemu-xen-traditional-dir/hw/xenfb.c.orig ? tools/qemu-xen-dir/hw/qxl.c.orig ? tools/qemu-xen-dir/hw/vga.c.orig ? tools/qemu-xen-dir/hw/vga_int.h.orig ? tools/blktap2/drivers/block-log.c.orig ? tools/libxl/libxl.c.orig ? tools/libxl/libxl_internal.h.orig M tools/libxl/libxl.c ? xen/include/public/io/ring.h.orig ? xen/arch/x86/cpu/common.c.orig ? xen/arch/x86/hvm/mtrr.c.orig ? xen/arch/x86/hvm/hvm.c.orig ? xen/arch/x86/mm/hap/hap.c.orig [bug 23530771] {CVE-2016-4962} [4.3.0-55.el6.119.44] - libxl: Do not trust frontend for vtpm in getinfo libxl_device_vtpm_getinfo needs to examine devices without trusting frontend-controlled data. So: * Use /libxl to find the backend path. * Parse the backend path to find the backend domid, rather than reading it from the frontend. This is part of XSA-175. Signed-off-by: Ian Jackson Reviewed-by: Wei Liu Upstream commit 3544831133b19787fc3d9a27711ff9f647d0ddb8 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23530771] {CVE-2016-4962} [4.3.0-55.el6.119.43] - libxl: Do not trust frontend for vtpm list libxl_device_vtpm_list needs to enumerate and identify devices without trusting frontend-controlled data. So * Use the /libxl path to enumerate vtpms. * Use the /libxl path to find the corresponding backends. * Parse the backend path to find the backend domid. This is part of XSA-175. Signed-off-by: Ian Jackson Reviewed-by: Wei Liu Upstream commit 7bde3f4c5d36c8e7760f74aad52546162a62c2b4 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23530771] {CVE-2016-4962} [4.3.0-55.el6.119.42] - libxl: Do not trust frontend for disk in getinfo * Rename the frontend variable to `fe_path' to check we caught them all * Read the backend path from /libxl, rather than from the frontend * Parse the backend domid from the backend path, rather than reading it from the frontend (and add the appropriate error path and initialisation) This is part of XSA-175. Signed-off-by: Ian Jackson Reviewed-by: Wei Liu Upstream commit 38ef6689b7cf3904355f95a0c12d0b92e5ad2137 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23530771] {CVE-2016-4962} [4.3.0-55.el6.119.41] - libxl: Do not trust frontend for disk eject event Use the /libxl path for interpreting disk eject watch events: do not read the backend path out of the frontend. Instead, use the version in /libxl. That avoids us relying on the guest-modifiable $frontend/backend pointer. To implement this we store the path /libxl/$guest/device/vbd/$devid/backend in the evgen structure. This is part of XSA-175. Signed-off-by: Ian Jackson Reviewed-by: Wei Liu Upstream commit babf4f45a52af68e58316c4456dffc97e0a1df79 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23530771] {CVE-2016-4962} [4.3.0-55.el6.119.40] - libxl: Do not trust frontend in libxl__device_nextid When selecting the devid for a new device, we should look in /libxl/device for existing devices, not in the frontend area. This is part of XSA-175. Signed-off-by: Ian Jackson Reviewed-by: Wei Liu Upstream commit 13de0ee03135a08c4e8cefa1981d638bb4d5a561 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23530771] {CVE-2016-4962} [4.3.0-55.el6.119.39] - libxl: Do not trust frontend in libxl__devices_destroy We need to enumerate the devices we have provided to a domain, without trusting the guest-writeable (or, at least, guest-deletable) frontend paths. Instead, enumerate via, and read the backend path from, /libxl. The console /libxl path is regular, so the special case for console 0 is not relevant any more: /libxl/GUEST/device/console/0 will be found, and then libxl__device_destroy will DTRT to the right frontend path. This is part of XSA-175. Signed-off-by: Ian Jackson Reviewed-by: Wei Liu Upstream commit 4a78d360241a4b97a22d83e6283e122a45ef96e3 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23530771] {CVE-2016-4962} [4.3.0-55.el6.119.38] - libxl: Provide libxl__backendpath_parse_domid Multiple places in libxl need to figure out the backend domid of a device. This can be discovered easily by looking at the backend path, which always starts /local/domain/$backend_domid/. There are no call sites yet. This is part of XSA-175. Signed-off-by: Ian Jackson Reviewed-by: Wei Liu Upstream commit 89c6672d012890894105d7f832ddf4cbf8d56a15 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23530771] {CVE-2016-4962} [4.3.0-55.el6.119.37] - libxl: Record backend/frontend paths in /libxl/$DOMID This gives us a record of all the backends we have set up for a domain, which is separate from the frontends in /local/domain/$DOMID/device. In particular: 1. A guest has write permission for the frontend path: /local/domain/$DOMID/device/$KIND/$DEVID which means that the guest can completely delete the frontend. (They can't recreate it because they don't have write permission on the containing directory.) 2. A guest has write permission for the backend path recorded in the frontend, ie, it can write to /local/domain/$DOMID/device/$KIND/$DEVID/backend which means that the guest can break the association between frontend and backend. So we can't rely on iterating over the frontends to find all the backends, or examining a frontend to discover how a device is configured. So, have libxl__device_generic_add record the frontend and backend paths in /libxl/$DOMID/device, and have libxl__device_destroy remove them again. Create the containing directory /libxl/GUEST/device in libxl__domain_make. The already existing xs_rm in devices_destroy_cb will take care of removing it. This is part of XSA-175. Backport note: Backported over 7472ced, which fixes a bug in driver domain teardown. Signed-off-by: Ian Jackson Reviewed-by: Wei Liu Upstream commit 44ea68c6e6819ee535c4dd3d18a8691ff722d961 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23530771] {CVE-2016-4962} [4.3.0-55.el6.119.36] - main loop: Big hammer to fix logfile disk DoS in Xen setups Each time round the main loop, we now fstat stderr. If it is too big, we dup2 /dev/null onto it. This is not a very pretty patch but it is very simple, easy to see that it's correct, and has a low risk of collateral damage. The limit is 1Mby by default but can be adjusted by setting a new environment variable. This fixes CVE-2014-3672. Signed-off-by: Ian Jackson Tested-by: Ian Jackson Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23531459] {CVE-2014-3672} [4.3.0-55.el6.119.35] - main loop: Big hammer to fix logfile disk DoS in Xen setups Each time round the main loop, we now fstat stderr. If it is too big, we dup2 /dev/null onto it. This is not a very pretty patch but it is very simple, easy to see that it's correct, and has a low risk of collateral damage. The limit is 1Mby by default but can be adjusted by setting a new environment variable. This fixes CVE-2014-3672. Signed-off-by: Ian Jackson Tested-by: Ian Jackson --- v2: Make it actually compile. Fix a typo in the message. Move the check_cve_2014_3672_xen up in the file, so that we can: Call check_cve_2014_3672_xen in the other copy of the main loop (!) Conflicts: tools/qemu-xen-dir/main-loop.c Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23531459] {CVE-2014-3672} [4.3.0-55.el6.119.34] - x86/mm: fully honor PS bits in guest page table walks In L4 entries it is currently unconditionally reserved (and hence should, when set, always result in a reserved bit page fault), and is reserved on hardware not supporting 1Gb pages (and hence should, when set, similarly cause a reserved bit page fault on such hardware). This is CVE-2016-4480 / XSA-176. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper Tested-by: Andrew Cooper Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23531401] {CVE-2016-4480} [4.3.0-55.el6.119.33] - x86: limit GFNs to 32 bits for shadowed superpages. Superpage shadows store the shadowed GFN in the backpointer field, which for non-BIGMEM builds is 32 bits wide. Shadowing a superpage mapping of a guest-physical address above 2^44 would lead to the GFN being truncated there, and a crash when we come to remove the shadow from the hash table. Track the valid width of a GFN for each guest, including reporting it through CPUID, and enforce it in the shadow pagetables. Set the maximum witth to 32 for guests where this truncation could occur. This is XSA-173. Signed-off-by: Tim Deegan Signed-off-by: Jan Beulich Reported-by: Ling Liu Upstream commit 95dd1b6e87b61222fc856724a5d828c9bdc30c80 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23530694] {CVE-2016-3960} [4.3.0-55.el6.119.32] - x86/HVM: correct CPUID leaf 80000008 handling CPUID[80000008].EAX[23:16] have been given the meaning of the guest physical address restriction (in case it needs to be smaller than the host's), hence we need to mirror that into vCPUID[80000008].EAX[7:0]. Enforce a lower limit at the same time, as well as a fixed value for the virtual address bits, and zero for the guest physical address ones. In order for the vMTRR code to see these overrides we need to make it call hvm_cpuid() instead of domain_cpuid(), which in turn requires special casing (and relaxing) the controlling domain. This additionally should hide an ordering problem in the tools: Both xend and xl appear to be restoring a guest from its image before setting up the CPUID policy in the hypervisor, resulting in domain_cpuid() returning all zeros and hence the check in mtrr_var_range_msr_set() failing if the guest previously had more than the minimum 36 physical address bits. Signed-off-by: Jan Beulich Reviewed-by: Tim Deegan Conflicts: xen/arch/x86/hvm/mtrr.c Upstream commit ef437690af8b75e6758dce77af75a22b63982883 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23530694] {CVE-2016-3960} [4.3.0-55.el6.119.31] - xenfb: avoid reading twice the same fields from the shared page Reading twice the same field could give the guest an attack of opportunity. In the case of event->type, gcc could compile the switch statement into a jump table, effectively ending up reading the type field multiple times. This is part of XSA-155. Signed-off-by: Stefano Stabellini Backported-by: Zhenzhong Duan [bug 23530451] {CVE-2015-8550} [4.3.0-55.el6.119.30] - xen/blkif: Avoid double access to src->nr_segments src is stored in shared memory and src->nr_segments is dereferenced twice at the end of the function. If a compiler decides to compile this into two separate memory accesses then the size limitation could be bypassed. Fix it by removing the double access to src->nr_segments. This is part of XSA-155. Signed-off-by: Stefano Stabellini Backported-by: Zhenzhong Duan [bug 23530451] {CVE-2015-8550} [4.3.0-55.el6.119.29] - xenfb: avoid reading twice the same fields from the shared page Reading twice the same field could give the guest an attack of opportunity. In the case of event->type, gcc could compile the switch statement into a jump table, effectively ending up reading the type field multiple times. This is part of XSA-155. Signed-off-by: Stefano Stabellini Upsteam commit 0ffd4547665d2fec648ab2c9ff856c5d9db9b07c Backported-by: Zhenzhong Duan Acked-by: Chuck Anderson [bug 23530451] {CVE-2015-8550} [4.3.0-55.el6.119.28] - blkif: Avoid double access to src->nr_segments src is stored in shared memory and src->nr_segments is dereferenced twice at the end of the function. If a compiler decides to compile this into two separate memory accesses then the size limitation could be bypassed. Fix it by removing the double access to src->nr_segments. This is part of XSA-155. Signed-off-by: Stefano Stabellini Signed-off-by: Konrad Rzeszutek Wilk Upsteam commit 27942b0cb2327e93deb12326bbe7b36c81f9fa7b Backported-by: Zhenzhong Duan [bug 23530451] {CVE-2015-8550} [4.3.0-55.el6.119.27] - libvchan: Read prod/cons only once. We must ensure that the prod/cons are only read once and that the compiler won't try to optimize the reads. That is split the read of these in multiple instructions influencing later branch code. As such insert barriers when fetching the cons and prod index. This is part of XSA155. Signed-off-by: Konrad Rzeszutek Wilk Backported-by: Zhenzhong Duan Acked-by: Chuck Anderson [bug 23530451] {CVE-2015-8550} [4.3.0-55.el6.119.26] - blktap2: Use RING_COPY_REQUEST Instead of RING_GET_REQUEST. Using a local copy of the ring (and also with proper memory barriers) will mean we can do not have to worry about the compiler optimizing the code and doing a double-fetch in the shared memory space. This is part of XSA155. Signed-off-by: Konrad Rzeszutek Wilk --- v2: Fix compile issues with tapdisk-vbd Upsteam commit 851ffb4eea917e2708c912291dea4d133026c0ac Backported-by: Zhenzhong Duan Acked-by: Chuck Anderson [bug 23530451] {CVE-2015-8550} [4.3.0-55.el6.119.25] - xen: Add RING_COPY_REQUEST() Using RING_GET_REQUEST() on a shared ring is easy to use incorrectly (i.e., by not considering that the other end may alter the data in the shared ring while it is being inspected). Safe usage of a request generally requires taking a local copy. Provide a RING_COPY_REQUEST() macro to use instead of RING_GET_REQUEST() and an open-coded memcpy(). This takes care of ensuring that the copy is done correctly regardless of any possible compiler optimizations. Use a volatile source to prevent the compiler from reordering or omitting the copy. This is part of XSA155. Signed-off-by: David Vrabel Signed-off-by: Konrad Rzeszutek Wilk --- v2: Add comment about GCC bug. Upsteam commit 12b11658a9d6a654a1e7acbf2f2d56ce9a396c86 Backported-by: Zhenzhong Duan Acked-by: Chuck Anderson [bug 23530451] {CVE-2015-8550} [4.3.0-55.el6.119.24] - vga: make sure vga register setup for vbe stays intact (CVE-2016-3712). Call vbe_update_vgaregs() when the guest touches GFX, SEQ or CRT registers, to make sure the vga registers will always have the values needed by vbe mode. This makes sure the sanity checks applied by vbe_fixup_regs() are effective. Without this guests can muck with shift_control, can turn on planar vga modes or text mode emulation while VBE is active, making qemu take code paths meant for CGA compatibility, but with the very large display widths and heigts settable using VBE registers. Which is good for one or another buffer overflow. Not that critical as they typically read overflows happening somewhere in the display code. So guests can DoS by crashing qemu with a segfault, but it is probably not possible to break out of the VM. Fixes: CVE-2016-3712 Reported-by: Zuozhi Fzz Reported-by: P J P Signed-off-by: Gerd Hoffmann Signed-off-by: Stefano Stabellini Upstream commit 0f2e9e6b3c75a87e9ec9a80d7bc914810e3f3da2 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3712} [4.3.0-55.el6.119.23] - vga: update vga register setup on vbe changes Call the new vbe_update_vgaregs() function on vbe configuration changes, to make sure vga registers are up-to-date. Signed-off-by: Gerd Hoffmann Signed-off-by: Stefano Stabellini Upstream commit 98be1fb6ea31c130264025de8ec87ad2c7532f21 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3712} [4.3.0-55.el6.119.22] - vga: factor out vga register setup When enabling vbe mode qemu will setup a bunch of vga registers to make sure the vga emulation operates in correct mode for a linear framebuffer. Move that code to a separate function so we can call it from other places too. Signed-off-by: Gerd Hoffmann Signed-off-by: Stefano Stabellini Upstream commit 2700250c6b28248b70b15fd6e0b4c9db8b2ddfb7 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3712} [4.3.0-55.el6.119.21] - vga: add vbe_enabled() helper Makes code a bit easier to read. Signed-off-by: Gerd Hoffmann Signed-off-by: Stefano Stabellini Upstream commit e7d7c09689c725be4f0b489b4ba3b741c5d9ab31 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3712} [4.3.0-55.el6.119.20] - vbe: rework sanity checks Plug a bunch of holes in the bochs dispi interface parameter checking. Add a function doing verification on all registers. Call that unconditionally on every register write. That way we should catch everything, even changing one register affecting the valid range of another register. Some of the holes have been added by commit e9c6149f6ae6873f14a12eea554925b6aa4c4dec. Before that commit the maximum possible framebuffer (VBE_DISPI_MAX_XRES * VBE_DISPI_MAX_YRES * 32 bpp) has been smaller than the qemu vga memory (8MB) and the checking for VBE_DISPI_MAX_XRES + VBE_DISPI_MAX_YRES + VBE_DISPI_MAX_BPP was ok. Some of the holes have been there forever, such as VBE_DISPI_INDEX_X_OFFSET and VBE_DISPI_INDEX_Y_OFFSET register writes lacking any verification. Security impact: (1) Guest can make the ui (gtk/vnc/...) use memory rages outside the vga frame buffer as source -> host memory leak. Memory isn't leaked to the guest but to the vnc client though. (2) Qemu will segfault in case the memory range happens to include unmapped areas -> Guest can DoS itself. The guest can not modify host memory, so I don't think this can be used by the guest to escape. CVE-2014-3615 Cc: qemu-stable at nongnu.org Cc: secalert at redhat.com Signed-off-by: Gerd Hoffmann Reviewed-by: Laszlo Ersek Conflicts: hw/vga.c Upstream commit c1b886c45dc70f247300f549dce9833f3fa2def5 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3712} [4.3.0-55.el6.119.19] - vbe: make bochs dispi interface return the correct memory size with qxl VgaState->vram_size is the size of the pci bar. In case of qxl not the whole pci bar can be used as vga framebuffer. Add a new variable vbe_size to handle that case. By default (if unset) it equals vram_size, but qxl can set vbe_size to something else. This makes sure VBE_DISPI_INDEX_VIDEO_MEMORY_64K returns correct results and sanity checks are done with the correct size too. Cc: qemu-stable at nongnu.org Signed-off-by: Gerd Hoffmann Reviewed-by: Laszlo Ersek Conflicts: hw/qxl.c hw/vga.c hw/vga_init.c Upstream commit 54a85d462447c1cb8a1638578a7fd086350b4d2d Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3712} [4.3.0-55.el6.119.18] - vga: fix banked access bounds checking (CVE-2016-3710) vga allows banked access to video memory using the window at 0xa00000 and it supports a different access modes with different address calculations. The VBE bochs extentions support banked access too, using the VBE_DISPI_INDEX_BANK register. The code tries to take the different address calculations into account and applies different limits to VBE_DISPI_INDEX_BANK depending on the current access mode. Which is probably effective in stopping misprogramming by accident. But from a security point of view completely useless as an attacker can easily change access modes after setting the bank register. Drop the bogus check, add range checks to vga_mem_{readb,writeb} instead. Fixes: CVE-2016-3710 Reported-by: Qinghao Tang Signed-off-by: Gerd Hoffmann Signed-off-by: Stefano Stabellini Upstream commit 67305fcf4733fb4fb9eacc33436ec66a7c0352ef Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3710} [4.3.0-55.el6.119.17] - vga: make sure vga register setup for vbe stays intact (CVE-2016-3712). Call vbe_update_vgaregs() when the guest touches GFX, SEQ or CRT registers, to make sure the vga registers will always have the values needed by vbe mode. This makes sure the sanity checks applied by vbe_fixup_regs() are effective. Without this guests can muck with shift_control, can turn on planar vga modes or text mode emulation while VBE is active, making qemu take code paths meant for CGA compatibility, but with the very large display widths and heigts settable using VBE registers. Which is good for one or another buffer overflow. Not that critical as they typically read overflows happening somewhere in the display code. So guests can DoS by crashing qemu with a segfault, but it is probably not possible to break out of the VM. Fixes: CVE-2016-3712 Reported-by: Zuozhi Fzz Reported-by: P J P Signed-off-by: Gerd Hoffmann [Backport to qemu-xen-tradition] Signed-off-by: Andrew Cooper Upstream commit 0b0cf8110e97b0cbd0da73d11163e26978822757 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3712} [4.3.0-55.el6.119.16] - vga: update vga register setup on vbe changes Call the new vbe_update_vgaregs() function on vbe configuration changes, to make sure vga registers are up-to-date. Signed-off-by: Gerd Hoffmann [Backport to qemu-xen-tradition] Signed-off-by: Andrew Cooper Upstream commit 5e840e6292825fcae90f6750a8f57bc989e28c5f Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3712} [4.3.0-55.el6.119.15] - vga: factor out vga register setup When enabling vbe mode qemu will setup a bunch of vga registers to make sure the vga emulation operates in correct mode for a linear framebuffer. Move that code to a separate function so we can call it from other places too. Signed-off-by: Gerd Hoffmann [Backport to qemu-xen-tradition] Signed-off-by: Andrew Cooper Upstream commit df228023ce39e8b72bd5a198b8703319b8b9ca23 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3712} [4.3.0-55.el6.119.14] - vga: add vbe_enabled() helper Makes code a bit easier to read. Signed-off-by: Gerd Hoffmann [Backport to qemu-xen-tradition] Signed-off-by: Andrew Cooper Upstream commit 34db09fb9967441408a1ff0579d553222cf17441 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3712} [4.3.0-55.el6.119.13] - CVE-2014-3615: vbe: rework sanity checks Backport of qemu-upstream: * c1b886c45dc70f247300f549dce9833f3fa2def5 Signed-off-by: Andrew Cooper Upstream commit 8a1e383df25477e21b48c67c93c3a4dde19f9e4f Prerequisite commit for CVE-2016-3712 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3712} [4.3.0-55.el6.119.12] - vga: fix banked access bounds checking (CVE-2016-3710) vga allows banked access to video memory using the window at 0xa00000 and it supports a different access modes with different address calculations. The VBE bochs extentions support banked access too, using the VBE_DISPI_INDEX_BANK register. The code tries to take the different address calculations into account and applies different limits to VBE_DISPI_INDEX_BANK depending on the current access mode. Which is probably effective in stopping misprogramming by accident. But from a security point of view completely useless as an attacker can easily change access modes after setting the bank register. Drop the bogus check, add range checks to vga_mem_{readb,writeb} instead. Fixes: CVE-2016-3710 Reported-by: Qinghao Tang Signed-off-by: Gerd Hoffmann [Backport to qemu-xen-tradition] Signed-off-by: Andrew Cooper Upstream commit bebb4f580901fb638016d9851a28dbb83d44b3a6 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3710} [4.3.0-55.el6.119.11] - x86: fix information leak on AMD CPUs The fix for XSA-52 was wrong, and so was the change synchronizing that new behavior to the FXRSTOR logic: AMD's manuals explictly state that writes to the ES bit are ignored, and it instead gets calculated from the exception and mask bits (it gets set whenever there is an unmasked exception, and cleared otherwise). Hence we need to follow that model in our workaround. This is XSA-172 / CVE-2016-3158. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper Acked-by: Chuck Anderson Reviewed-by: Boris Ostrovsky Tested-by: Boris Ostrovsky [bug 23006897] {CVE-2016-3158,CVE-2016-3159} From oraclevm-errata at oss.oracle.com Wed Jul 27 12:20:04 2016 From: oraclevm-errata at oss.oracle.com (Errata Announcements for Oracle VM) Date: Wed, 27 Jul 2016 12:20:04 -0700 Subject: [Oraclevm-errata] OVMSA-2016-0090 Important: Oracle VM 3.2 xen security update Message-ID: <57990964.2040306@oracle.com> Oracle VM Security Advisory OVMSA-2016-0090 The following updated rpms for Oracle VM 3.2 have been uploaded to the Unbreakable Linux Network: x86_64: xen-4.1.3-25.el5.223.34.x86_64.rpm xen-devel-4.1.3-25.el5.223.34.x86_64.rpm xen-tools-4.1.3-25.el5.223.34.x86_64.rpm SRPMS: http://oss.oracle.com/oraclevm/server/3.2/SRPMS-updates/xen-4.1.3-25.el5.223.34.src.rpm Description of changes: [4.1.3-25.el5.223.34] - x86/HVM: correct CPUID leaf 80000008 handling - 6c733e54 xsa173_01_0001-x86-HVM-correct-CPUID-leaf-80000008-handling.patch was based on upstream commit: ef437690af8b75e6758dce77af75a22b63982883 x86/HVM: correct CPUID leaf 80000008 handling It should have been based on upstream commit: 6c733e549889a9b8c4e03140348b8e00241d4ce9 x86/HVM: correct CPUID leaf 80000008 handling The changes in this patch are the differences between those two patches. Signed-off-by: Chuck Anderson Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Boris Ostrovsky [bug 24356444] [4.1.3-25.el5.223.33] - x86/pv: Remove unsafe bits from the mod_l?_entry() fastpath All changes in writeability and cacheability must go through full re-validation. Rework the logic as a whitelist, to make it clearer to follow. This is XSA-182 Signed-off-by: Andrew Cooper Reviewed-by: Tim Deegan Upstream commit 798c1498f764bfaa7b0b955bab40b01b0610d372 Conflicts: xen/include/asm-x86/page.h Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 24307902] [4.1.3-25.el5.223.32] - x86/mm: fully honor PS bits in guest page table walks In L4 entries it is currently unconditionally reserved (and hence should, when set, always result in a reserved bit page fault), and is reserved on hardware not supporting 1Gb pages (and hence should, when set, similarly cause a reserved bit page fault on such hardware). This is CVE-2016-4480 / XSA-176. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper Tested-by: Andrew Cooper Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23531409] {CVE-2016-4480} [4.1.3-25.el5.223.31] - x86/mm: Handle 1GiB superpages in the pagetable walker. This allows HAP guests to use 1GiB superpages. Shadow and PV guests still can't use them without more support in shadow/* and mm.c. Signed-off-by: Christoph Egger Signed-off-by: Tim Deegan Conflicts: xen/arch/x86/hvm/hvm.c xen/arch/x86/mm/guest_walk.c Backported from upstream commit 96b740e209d0bea4c16d93211ceb139fc98d10c2 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23531409] {CVE-2016-4480} [4.1.3-25.el5.223.30] - main loop: Big hammer to fix logfile disk DoS in Xen setups Each time round the main loop, we now fstat stderr. If it is too big, we dup2 /dev/null onto it. This is not a very pretty patch but it is very simple, easy to see that it's correct, and has a low risk of collateral damage. The limit is 1Mby by default but can be adjusted by setting a new environment variable. This fixes CVE-2014-3672. Signed-off-by: Ian Jackson Tested-by: Ian Jackson Backported-by: Zhenzhong Duan [bug 23531487] {CVE-2014-3672} [4.1.3-25.el5.223.29] - x86: make hvm_cpuid() tolerate NULL pointers Now that other HVM code started making more extensive use of hvm_cpuid(), let's not force every caller to declare dummy variables for output not cared about. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper Acked-by: Boris Ostrovsky Acked-by: Jun Nakajima xen/arch/x86/hvm/svm/svm.c and xen/arch/x86/hvm/vmx/vvmx.c part are removed as no source matched. Upstream commit 11b85dbd0ab068bad3beadda3aee2298205a3c01 Signed-off-by: Zhenzhong Duan [bug 23500509] [4.1.3-25.el5.223.28] - x86: limit GFNs to 32 bits for shadowed superpages. Superpage shadows store the shadowed GFN in the backpointer field, which for non-BIGMEM builds is 32 bits wide. Shadowing a superpage mapping of a guest-physical address above 2^44 would lead to the GFN being truncated there, and a crash when we come to remove the shadow from the hash table. Track the valid width of a GFN for each guest, including reporting it through CPUID, and enforce it in the shadow pagetables. Set the maximum witth to 32 for guests where this truncation could occur. This is XSA-173. Signed-off-by: Tim Deegan Signed-off-by: Jan Beulich Reported-by: Ling Liu Conflicts: xen/arch/x86/cpu/common.c arch/x86/mm/guest_walk.c Upstream commit 95dd1b6e87b61222fc856724a5d828c9bdc30c80 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23170585] {CVE-2016-3960} [4.1.3-25.el5.223.27] - x86/HVM: correct CPUID leaf 80000008 handling CPUID[80000008].EAX[23:16] have been given the meaning of the guest physical address restriction (in case it needs to be smaller than the host's), hence we need to mirror that into vCPUID[80000008].EAX[7:0]. Enforce a lower limit at the same time, as well as a fixed value for the virtual address bits, and zero for the guest physical address ones. In order for the vMTRR code to see these overrides we need to make it call hvm_cpuid() instead of domain_cpuid(), which in turn requires special casing (and relaxing) the controlling domain. This additionally should hide an ordering problem in the tools: Both xend and xl appear to be restoring a guest from its image before setting up the CPUID policy in the hypervisor, resulting in domain_cpuid() returning all zeros and hence the check in mtrr_var_range_msr_set() failing if the guest previously had more than the minimum 36 physical address bits. Signed-off-by: Jan Beulich Reviewed-by: Tim Deegan Conflicts: xen/arch/x86/hvm/mtrr.c Upstream commit ef437690af8b75e6758dce77af75a22b63982883 Backported-by: Zhenzhong Duan Reviewed-by: Boris Ostrovsky [bug 23170585] {CVE-2016-3960} From oraclevm-errata at oss.oracle.com Fri Jul 29 16:25:08 2016 From: oraclevm-errata at oss.oracle.com (Errata Announcements for Oracle VM) Date: Fri, 29 Jul 2016 16:25:08 -0700 Subject: [Oraclevm-errata] OVMSA-2016-0091 Important: Oracle VM 3.4 kernel-uek security update Message-ID: <579BE5D4.1000301@oracle.com> Oracle VM Security Advisory OVMSA-2016-0091 The following updated rpms for Oracle VM 3.4 have been uploaded to the Unbreakable Linux Network: x86_64: kernel-uek-4.1.12-37.6.1.el6uek.x86_64.rpm kernel-uek-firmware-4.1.12-37.6.1.el6uek.noarch.rpm SRPMS: http://oss.oracle.com/oraclevm/server/3.4/SRPMS-updates/kernel-uek-4.1.12-37.6.1.el6uek.src.rpm Description of changes: [4.1.12-37.6.1.el6uek] - vfs: rename: check backing inode being equal (Miklos Szeredi) [Orabug: 24010060] {CVE-2016-6198} {CVE-2016-6197} - vfs: add vfs_select_inode() helper (Miklos Szeredi) [Orabug: 24010060] {CVE-2016-6198} {CVE-2016-6197} - ovl: verify upper dentry before unlink and rename (Miklos Szeredi) [Orabug: 24010060] {CVE-2016-6198} {CVE-2016-6197} - ovl: fix getcwd() failure after unsuccessful rmdir (Rui Wang) [Orabug: 24010060] {CVE-2016-6198} {CVE-2016-6197} - xen: use same main loop for counting and remapping pages (Juergen Gross) [Orabug: 24012238] - Revert "ocfs2: bump up o2cb network protocol version" (Junxiao Bi) [Orabug: 23710417] - atl2: Disable unimplemented scatter/gather feature (Ben Hutchings) [Orabug: 23704078] {CVE-2016-2117} - Revert "perf tools: Bump default sample freq to 4 kHz" (ashok.vairavan) [Orabug: 23634802] - block: Initialize max_dev_sectors to 0 (Keith Busch) [Orabug: 23333444] - sd: Fix rw_max for devices that report an optimal xfer size (Martin K. Petersen) [Orabug: 23333444] - sd: Fix excessive capacity printing on devices with blocks bigger than 512 bytes (Martin K. Petersen) [Orabug: 23333444] - sd: Optimal I/O size is in bytes, not sectors (Martin K. Petersen) [Orabug: 23333444] - sd: Reject optimal transfer length smaller than page size (Martin K. Petersen) [Orabug: 23333444] - Fix kabi issue for upstream commit ca369d51 (Joe Jin) [Orabug: 23333444] - block/sd: Fix device-imposed transfer length limits (Joe Jin) [Orabug: 23333444] From oraclevm-errata at oss.oracle.com Fri Jul 29 16:28:48 2016 From: oraclevm-errata at oss.oracle.com (Errata Announcements for Oracle VM) Date: Fri, 29 Jul 2016 16:28:48 -0700 Subject: [Oraclevm-errata] OVMSA-2016-0092 Important: Oracle VM 3.3 kernel-uek security update Message-ID: <579BE6B0.6060507@oracle.com> Oracle VM Security Advisory OVMSA-2016-0092 The following updated rpms for Oracle VM 3.3 have been uploaded to the Unbreakable Linux Network: x86_64: kernel-uek-3.8.13-118.9.1.el6uek.x86_64.rpm kernel-uek-firmware-3.8.13-118.9.1.el6uek.noarch.rpm SRPMS: http://oss.oracle.com/oraclevm/server/3.3/SRPMS-updates/kernel-uek-3.8.13-118.9.1.el6uek.src.rpm Description of changes: [3.8.13-118.9.1.el6uek] - mlx4: Increase SYNC_TPT command timeout (Mukesh Kacker) [Orabug: 22895790] - neigh: do not modify unlinked entries (Julian Anastasov) [Orabug: 23072705] - mm/slab: Improve performance of slabinfo stats gathering (Aruna Ramakrishna) [Orabug: 23720437] - atl2: Disable unimplemented scatter/gather feature (Ben Hutchings) [Orabug: 23703901] {CVE-2016-2117} {CVE-2016-2117}