Hello community, here is the log from the commit of package xen for openSUSE:Factory checked in at 2016-01-08 15:21:56 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comparing /work/SRC/openSUSE:Factory/xen (Old) and /work/SRC/openSUSE:Factory/.xen.new (New) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "xen" Changes: -------- --- /work/SRC/openSUSE:Factory/xen/xen.changes 2016-01-01 19:47:04.000000000 +0100 +++ /work/SRC/openSUSE:Factory/.xen.new/xen.changes 2016-01-08 15:21:58.000000000 +0100 @@ -1,0 +2,7 @@ +Mon Jan 4 11:32:10 MST 2016 - [email protected] + +- bsc#960093 - VUL-0: CVE-2015-8615: xen: x86: unintentional + logging upon guest changing callback method (XSA-169) + 5677f350-x86-make-debug-output-consistent-in-hvm_set_callback_via.patch + +------------------------------------------------------------------- @@ -6,0 +14,73 @@ + +------------------------------------------------------------------- +Wed Dec 16 12:16:21 MST 2015 - [email protected] + +- bsc#959387 - VUL-0: CVE-2015-8568 CVE-2015-8567: xen: qemu: net: + vmxnet3: host memory leakage + CVE-2015-8568-qemuu-net-vmxnet3-avoid-memory-leakage-in-activate_device.patch + +------------------------------------------------------------------- +Mon Dec 14 10:12:05 MST 2015 - [email protected] + +- bsc#957988 - VUL-0: CVE-2015-8550: xen: paravirtualized drivers + incautious about shared memory contents (XSA-155) + xsa155-xen-0001-xen-Add-RING_COPY_REQUEST.patch + xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch + xsa155-xen-0003-libvchan-Read-prod-cons-only-once.patch + xsa155-qemuu-qdisk-double-access.patch + xsa155-qemut-qdisk-double-access.patch + xsa155-qemuu-xenfb.patch + xsa155-qemut-xenfb.patch +- bsc#959006 - VUL-0: CVE-2015-8558: xen: qemu: usb: infinite loop + in ehci_advance_state results in DoS + CVE-2015-8558-qemuu-usb-infinite-loop-in-ehci_advance_state-results-in-DoS.patch +- bsc#958918 - VUL-0: CVE-2015-7549: xen: qemu pci: null pointer + dereference issue + CVE-2015-7549-qemuu-pci-null-pointer-dereference-issue.patch +- bsc#958493 - VUL-0: CVE-2015-8504: xen: qemu: ui: vnc: avoid + floating point exception + CVE-2015-8504-qemuu-vnc-avoid-floating-point-exception.patch + CVE-2015-8504-qemut-vnc-avoid-floating-point-exception.patch +- bsc#958007 - VUL-0: CVE-2015-8554: xen: qemu-dm buffer overrun in + MSI-X handling (XSA-164) + xsa164.patch +- bsc#958009 - VUL-0: CVE-2015-8555: xen: information leak in + legacy x86 FPU/XMM initialization (XSA-165) + xsa165.patch +- bsc#958523 - VUL-0: xen: ioreq handling possibly susceptible to + multiple read issue (XSA-166) + xsa166.patch + +------------------------------------------------------------------- +Fri Nov 27 10:39:38 MST 2015 - [email protected] + +- bsc#956832 - VUL-0: CVE-2015-8345: xen: qemu: net: eepro100: + infinite loop in processing command block list + CVE-2015-8345-qemuu-eepro100-infinite-loop-fix.patch + CVE-2015-8345-qemut-eepro100-infinite-loop-fix.patch +- Upstream patches from Jan + 56377442-x86-PoD-Make-p2m_pod_empty_cache-restartable.patch + 5641ceec-x86-HVM-always-intercept-AC-and-DB.patch (Replaces CVE-2015-5307-xsa156.patch) + 5644b756-x86-HVM-don-t-inject-DB-with-error-code.patch + 56544a57-VMX-fix-adjust-trap-injection.patch + 56546ab2-sched-fix-insert_vcpu-locking.patch + +------------------------------------------------------------------- +Wed Nov 25 10:06:30 MST 2015 - [email protected] + +- bsc#956592 - VUL-0: xen: virtual PMU is unsupported (XSA-163) + 56549f24-x86-vPMU-document-as-unsupported.patch +- bsc#956408 - VUL-0: CVE-2015-8339, CVE-2015-8340: xen: + XENMEM_exchange error handling issues (XSA-159) + xsa159.patch +- bsc#956409 - VUL-0: CVE-2015-8341: xen: libxl leak of pv kernel + and initrd on error (XSA-160) + xsa160.patch +- bsc#956411 - VUL-0: CVE-2015-7504: xen: heap buffer overflow + vulnerability in pcnet emulator (XSA-162) + xsa162-qemuu.patch + xsa162-qemut.patch +- bsc#947165 - VUL-0: CVE-2015-7311: xen: libxl fails to honour + readonly flag on disks with qemu-xen (xsa-142) + 5628fc67-libxl-No-emulated-disk-driver-for-xvdX-disk.patch + 5649bcbe-libxl-relax-readonly-check-introduced-by-XSA-142-fix.patch New: ---- 5628fc67-libxl-No-emulated-disk-driver-for-xvdX-disk.patch 5649bcbe-libxl-relax-readonly-check-introduced-by-XSA-142-fix.patch 56549f24-x86-vPMU-document-as-unsupported.patch 5677f350-x86-make-debug-output-consistent-in-hvm_set_callback_via.patch CVE-2015-7549-qemuu-pci-null-pointer-dereference-issue.patch CVE-2015-8345-qemut-eepro100-infinite-loop-fix.patch CVE-2015-8345-qemuu-eepro100-infinite-loop-fix.patch CVE-2015-8504-qemut-vnc-avoid-floating-point-exception.patch CVE-2015-8504-qemuu-vnc-avoid-floating-point-exception.patch CVE-2015-8558-qemuu-usb-infinite-loop-in-ehci_advance_state-results-in-DoS.patch CVE-2015-8568-qemuu-net-vmxnet3-avoid-memory-leakage-in-activate_device.patch xsa155-qemut-qdisk-double-access.patch xsa155-qemut-xenfb.patch xsa155-qemuu-qdisk-double-access.patch xsa155-qemuu-xenfb.patch xsa155-xen-0001-xen-Add-RING_COPY_REQUEST.patch xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch xsa155-xen-0003-libvchan-Read-prod-cons-only-once.patch xsa159.patch xsa160.patch xsa162-qemut.patch xsa162-qemuu.patch xsa164.patch xsa165.patch xsa166.patch ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ xen.spec ++++++ --- /var/tmp/diff_new_pack.SC0B16/_old 2016-01-08 15:22:01.000000000 +0100 +++ /var/tmp/diff_new_pack.SC0B16/_new 2016-01-08 15:22:01.000000000 +0100 @@ -1,7 +1,7 @@ # # spec file for package xen # -# Copyright (c) 2015 SUSE LINUX GmbH, Nuernberg, Germany. +# Copyright (c) 2016 SUSE LINUX GmbH, Nuernberg, Germany. # # All modifications and additions to the file contributed by third parties # remain the property of their copyright owners, unless otherwise agreed @@ -163,7 +163,7 @@ %endif %endif -Version: 4.6.0_04 +Version: 4.6.0_06 Release: 0 Summary: Xen Virtualization: Hypervisor (aka VMM aka Microkernel) License: GPL-2.0 @@ -209,18 +209,36 @@ Patch4: 561d2046-VT-d-use-proper-error-codes-in-iommu_enable_x2apic_IR.patch Patch5: 561d20a0-x86-hide-MWAITX-from-PV-domains.patch Patch6: 561e3283-x86-NUMA-fix-SRAT-table-processor-entry-parsing-and-consumption.patch -Patch7: 5632118e-arm-Support-hypercall_create_continuation-for-multicall.patch -Patch8: 56321222-arm-rate-limit-logging-from-unimplemented-PHYSDEVOP-and-HVMOP.patch -Patch9: 56321249-arm-handle-races-between-relinquish_memory-and-free_domheap_pages.patch -Patch10: 5632127b-x86-guard-against-undue-super-page-PTE-creation.patch -Patch11: 5632129c-free-domain-s-vcpu-array.patch -Patch12: 563212c9-x86-PoD-Eager-sweep-for-zeroed-pages.patch -Patch13: 563212e4-xenoprof-free-domain-s-vcpu-array.patch -Patch14: 563212ff-x86-rate-limit-logging-in-do_xen-oprof-pmu-_op.patch -Patch15: 56323737-libxl-adjust-PoD-target-by-memory-fudge-too.patch -Patch16: 56377442-x86-PoD-Make-p2m_pod_empty_cache-restartable.patch -Patch17: 5641ceec-x86-HVM-always-intercept-AC-and-DB.patch -Patch18: 5644b756-x86-HVM-don-t-inject-DB-with-error-code.patch +Patch7: 5628fc67-libxl-No-emulated-disk-driver-for-xvdX-disk.patch +Patch8: 5632118e-arm-Support-hypercall_create_continuation-for-multicall.patch +Patch9: 56321222-arm-rate-limit-logging-from-unimplemented-PHYSDEVOP-and-HVMOP.patch +Patch10: 56321249-arm-handle-races-between-relinquish_memory-and-free_domheap_pages.patch +Patch11: 5632127b-x86-guard-against-undue-super-page-PTE-creation.patch +Patch12: 5632129c-free-domain-s-vcpu-array.patch +Patch13: 563212c9-x86-PoD-Eager-sweep-for-zeroed-pages.patch +Patch14: 563212e4-xenoprof-free-domain-s-vcpu-array.patch +Patch15: 563212ff-x86-rate-limit-logging-in-do_xen-oprof-pmu-_op.patch +Patch16: 56323737-libxl-adjust-PoD-target-by-memory-fudge-too.patch +Patch17: 56377442-x86-PoD-Make-p2m_pod_empty_cache-restartable.patch +Patch18: 5641ceec-x86-HVM-always-intercept-AC-and-DB.patch +Patch19: 5644b756-x86-HVM-don-t-inject-DB-with-error-code.patch +Patch20: 5649bcbe-libxl-relax-readonly-check-introduced-by-XSA-142-fix.patch +Patch21: 56549f24-x86-vPMU-document-as-unsupported.patch +Patch22: 5677f350-x86-make-debug-output-consistent-in-hvm_set_callback_via.patch +Patch15501: xsa155-xen-0001-xen-Add-RING_COPY_REQUEST.patch +Patch15502: xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch +Patch15503: xsa155-xen-0003-libvchan-Read-prod-cons-only-once.patch +Patch15504: xsa155-qemuu-qdisk-double-access.patch +Patch15505: xsa155-qemut-qdisk-double-access.patch +Patch15506: xsa155-qemuu-xenfb.patch +Patch15507: xsa155-qemut-xenfb.patch +Patch159: xsa159.patch +Patch160: xsa160.patch +Patch16201: xsa162-qemuu.patch +Patch16202: xsa162-qemut.patch +Patch164: xsa164.patch +Patch165: xsa165.patch +Patch166: xsa166.patch # Upstream qemu Patch250: VNC-Support-for-ExtendedKeyEvent-client-message.patch Patch251: 0001-net-move-the-tap-buffer-into-TAPState.patch @@ -235,6 +253,13 @@ Patch260: CVE-2015-4037-qemut-smb-config-dir-name.patch Patch261: CVE-2014-0222-qemuu-qcow1-validate-l2-table-size.patch Patch262: CVE-2014-0222-qemut-qcow1-validate-l2-table-size.patch +Patch263: CVE-2015-8345-qemuu-eepro100-infinite-loop-fix.patch +Patch264: CVE-2015-8345-qemut-eepro100-infinite-loop-fix.patch +Patch265: CVE-2015-8504-qemut-vnc-avoid-floating-point-exception.patch +Patch266: CVE-2015-8504-qemuu-vnc-avoid-floating-point-exception.patch +Patch267: CVE-2015-7549-qemuu-pci-null-pointer-dereference-issue.patch +Patch268: CVE-2015-8558-qemuu-usb-infinite-loop-in-ehci_advance_state-results-in-DoS.patch +Patch269: CVE-2015-8568-qemuu-net-vmxnet3-avoid-memory-leakage-in-activate_device.patch # Our platform specific patches Patch301: xen-destdir.patch Patch302: vif-bridge-no-iptables.patch @@ -522,6 +547,24 @@ %patch16 -p1 %patch17 -p1 %patch18 -p1 +%patch19 -p1 +%patch20 -p1 +%patch21 -p1 +%patch22 -p1 +%patch15501 -p1 +%patch15502 -p1 +%patch15503 -p1 +%patch15504 -p1 +%patch15505 -p1 +%patch15506 -p1 +%patch15507 -p1 +%patch159 -p1 +%patch160 -p1 +%patch16201 -p1 +%patch16202 -p1 +%patch164 -p1 +%patch165 -p1 +%patch166 -p1 # Upstream qemu patches %patch250 -p1 %patch251 -p1 @@ -536,6 +579,13 @@ %patch260 -p1 %patch261 -p1 %patch262 -p1 +%patch263 -p1 +%patch264 -p1 +%patch265 -p1 +%patch266 -p1 +%patch267 -p1 +%patch268 -p1 +%patch269 -p1 # Our platform specific patches %patch301 -p1 %patch302 -p1 ++++++ 5628fc67-libxl-No-emulated-disk-driver-for-xvdX-disk.patch ++++++ Subject: libxl: No emulated disk driver for xvdX disk From: Anthony PERARD [email protected] Wed Oct 14 12:05:17 2015 +0100 Date: Thu Oct 22 16:10:31 2015 +0100: Git: c0c099d157cc5bc942afef766cf141628a6380a1 When a guest configuration list xvdX for its disks, there is no need to provide an emulated driver for the same target. Such configuration can work with the OVMF firmware, as it supports PV disk. Signed-off-by: Anthony PERARD <[email protected]> Acked-by: Ian Jackson <[email protected]> Index: xen-4.6.0-testing/tools/libxl/libxl_dm.c =================================================================== --- xen-4.6.0-testing.orig/tools/libxl/libxl_dm.c +++ xen-4.6.0-testing/tools/libxl/libxl_dm.c @@ -1152,6 +1152,12 @@ static int libxl__build_device_model_arg drive = libxl__sprintf (gc, "file=%s,if=scsi,bus=0,unit=%d,format=%s,cache=writeback", pdev_path, disk, format); + else if (strncmp(disks[i].vdev, "xvd", 3) == 0) + /* + * Do not add any emulated disk when PV disk are + * explicitly asked for. + */ + continue; else if (disk < 6 && b_info->u.hvm.hdtype == LIBXL_HDTYPE_AHCI) { flexarray_vappend(dm_args, "-drive", GCSPRINTF("file=%s,if=none,id=ahcidisk-%d,format=%s,cache=writeback", ++++++ 5649bcbe-libxl-relax-readonly-check-introduced-by-XSA-142-fix.patch ++++++ Subject: libxl: relax readonly check introduced by XSA-142 fix From: Jim Fehlig [email protected] Thu Nov 12 19:40:46 2015 -0700 Date: Mon Nov 16 11:23:42 2015 +0000: Git: ef6cb76026628e26e3d1ae53c50ccde1c3c78b1b The fix for XSA-142 is quite a big hammer, rejecting readonly disk configuration even when the requested backend is known to support readonly. While it is true that qemu doesn't support readonly for emulated IDE or AHCI disks $ /usr/lib/xen/bin/qemu-system-i386 \ -drive file=/tmp/disk.raw,if=ide,media=disk,format=raw,readonly=on qemu-system-i386: Can't use a read-only drive $ /usr/lib/xen/bin/qemu-system-i386 -device ahci,id=ahci0 \ -drive file=/tmp/disk.raw,if=none,id=ahcidisk-0,format=raw,readonly=on \ -device ide-hd,bus=ahci0.0,unit=0,drive=ahcidisk-0 qemu-system-i386: -device ide-hd,bus=ahci0.0,unit=0,drive=ahcidisk-0: Can't use a read-only drive It does support readonly SCSI disks $ /usr/lib/xen/bin/qemu-system-i386 \ -drive file=/tmp/disk.raw,if=scsi,media=disk,format=raw,readonly=on [ok] Inside a guest using such a disk, the SCSI kernel driver sees write protect on [ 7.339232] sd 2:0:1:0: [sdb] Write Protect is on Also, PV drivers support readonly, but the patch rejects such configuration even when PV drivers (vdev=xvd*) have been explicitly specified and creation of an emulated twin is skiped. This follow-up patch loosens the restriction to reject readonly when creating an emulated IDE or AHCI disk, but allows it when the backend is known to support readonly. Signed-off-by: Jim Fehlig <[email protected]> Acked-by: Stefano Stabellini <[email protected]> Acked-by: Ian Campbell <[email protected]> Index: xen-4.6.0-testing/tools/libxl/libxl_dm.c =================================================================== --- xen-4.6.0-testing.orig/tools/libxl/libxl_dm.c +++ xen-4.6.0-testing/tools/libxl/libxl_dm.c @@ -1117,11 +1117,6 @@ static int libxl__build_device_model_arg (gc, "file=%s,if=ide,index=%d,readonly=%s,media=cdrom,format=%s,cache=writeback,id=ide-%i", disks[i].pdev_path, disk, disks[i].readwrite ? "off" : "on", format, dev_number); } else { - if (!disks[i].readwrite) { - LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "qemu-xen doesn't support read-only disk drivers"); - return ERROR_INVAL; - } - if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY) { LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "cannot support" " empty disk format for %s", disks[i].vdev); @@ -1148,29 +1143,38 @@ static int libxl__build_device_model_arg * For other disks we translate devices 0..3 into * hd[a-d] and ignore the rest. */ - if (strncmp(disks[i].vdev, "sd", 2) == 0) + if (strncmp(disks[i].vdev, "sd", 2) == 0) { drive = libxl__sprintf - (gc, "file=%s,if=scsi,bus=0,unit=%d,format=%s,cache=writeback", - pdev_path, disk, format); - else if (strncmp(disks[i].vdev, "xvd", 3) == 0) + (gc, "file=%s,if=scsi,bus=0,unit=%d,format=%s,readonly=%s,cache=writeback", + pdev_path, disk, format, disks[i].readwrite ? "off" : "on"); + } else if (strncmp(disks[i].vdev, "xvd", 3) == 0) { /* * Do not add any emulated disk when PV disk are * explicitly asked for. */ continue; - else if (disk < 6 && b_info->u.hvm.hdtype == LIBXL_HDTYPE_AHCI) { + } else if (disk < 6 && b_info->u.hvm.hdtype == LIBXL_HDTYPE_AHCI) { + if (!disks[i].readwrite) { + LOG(ERROR, "qemu-xen doesn't support read-only AHCI disk drivers"); + return ERROR_INVAL; + } flexarray_vappend(dm_args, "-drive", GCSPRINTF("file=%s,if=none,id=ahcidisk-%d,format=%s,cache=writeback", pdev_path, disk, format), "-device", GCSPRINTF("ide-hd,bus=ahci0.%d,unit=0,drive=ahcidisk-%d", disk, disk), NULL); continue; - } else if (disk < 4) + } else if (disk < 4) { + if (!disks[i].readwrite) { + LOG(ERROR, "qemu-xen doesn't support read-only IDE disk drivers"); + return ERROR_INVAL; + } drive = libxl__sprintf (gc, "file=%s,if=ide,index=%d,media=disk,format=%s,cache=writeback", pdev_path, disk, format); - else + } else { continue; /* Do not emulate this disk */ + } } flexarray_append(dm_args, "-drive"); ++++++ 56549f24-x86-vPMU-document-as-unsupported.patch ++++++ # Commit c03480cf5c4e96fb4afb2237ad0a3cac7162564a # Date 2015-11-24 18:32:20 +0100 # Author Jan Beulich <[email protected]> # Committer Jan Beulich <[email protected]> x86/vPMU: document as unsupported This is XSA-163. Signed-off-by: Jan Beulich <[email protected]> Index: xen-4.6.0-testing/docs/misc/xen-command-line.markdown =================================================================== --- xen-4.6.0-testing.orig/docs/misc/xen-command-line.markdown +++ xen-4.6.0-testing/docs/misc/xen-command-line.markdown @@ -1463,8 +1463,8 @@ feature is switched on on Intel processo Note that if **watchdog** option is also specified vpmu will be turned off. *Warning:* -As the BTS virtualisation is not 100% safe and because of the nehalem quirk -don't use the vpmu flag on production systems with Intel cpus! +As the virtualisation is not 100% safe, don't use the vpmu flag on +production systems (see http://xenbits.xen.org/xsa/advisory-163.html)! ### watchdog > `= force | <boolean>` ++++++ 5677f350-x86-make-debug-output-consistent-in-hvm_set_callback_via.patch ++++++ Reference: bsc#960093 CVE-2015-8615 XSA-169 Subject: x86: make debug output consistent in hvm_set_callback_via From: Malcolm Crossley [email protected] Mon Dec 21 13:40:48 2015 +0100 Date: Mon Dec 21 13:40:48 2015 +0100: Git: 5c1048565ba5b240f47203bdb67572bee73d639e The unconditional printks in the switch statement of the hvm_set_callback_via function results in Xen log spam in non debug versions of Xen. The printks are for debug output only so conditionally compile the entire switch statement on debug versions of Xen only. This is XSA-169. Signed-off-by: Malcolm Crossley <[email protected]> Reviewed-by: Jan Beulich <[email protected]> Acked-by: Ian Campbell <[email protected]> Index: xen-4.6.0-testing/xen/arch/x86/hvm/irq.c =================================================================== --- xen-4.6.0-testing.orig/xen/arch/x86/hvm/irq.c +++ xen-4.6.0-testing/xen/arch/x86/hvm/irq.c @@ -382,7 +382,8 @@ void hvm_set_callback_via(struct domain spin_unlock(&d->arch.hvm_domain.irq_lock); - dprintk(XENLOG_G_INFO, "Dom%u callback via changed to ", d->domain_id); +#ifndef NDEBUG + printk(XENLOG_G_INFO "Dom%u callback via changed to ", d->domain_id); switch ( via_type ) { case HVMIRQ_callback_gsi: @@ -398,6 +399,7 @@ void hvm_set_callback_via(struct domain printk("None\n"); break; } +#endif } struct hvm_intack hvm_vcpu_has_pending_irq(struct vcpu *v) ++++++ CVE-2015-7549-qemuu-pci-null-pointer-dereference-issue.patch ++++++ References: bsc#958918 CVE-2015-7549 Subject: msix: implement pba write (but read-only) From: Marc-André Lureau [email protected] Fri Jun 26 14:25:29 2015 +0200 Date: Sat Oct 24 18:03:18 2015 +0200: Git: 43b11a91dd861a946b231b89b7542856ade23d1b qpci_msix_pending() writes on pba region, causing qemu to SEGV: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff7fba8c0 (LWP 25882)] 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in () #1 0x00005555556556c5 in memory_region_oldmmio_write_accessor (mr=0x5555579f3f80, addr=0, value=0x7fffffffbf68, size=4, shift=0, mask=4294967295, attrs=...) at /home/elmarco/src/qemu/memory.c:434 #2 0x00005555556558e1 in access_with_adjusted_size (addr=0, value=0x7fffffffbf68, size=4, access_size_min=1, access_size_max=4, access=0x55555565563e <memory_region_oldmmio_write_accessor>, mr=0x5555579f3f80, attrs=...) at /home/elmarco/src/qemu/memory.c:506 #3 0x00005555556581eb in memory_region_dispatch_write (mr=0x5555579f3f80, addr=0, data=0, size=4, attrs=...) at /home/elmarco/src/qemu/memory.c:1176 #4 0x000055555560b6f9 in address_space_rw (as=0x555555eff4e0 <address_space_memory>, addr=3759147008, attrs=..., buf=0x7fffffffc1b0 "", len=4, is_write=true) at /home/elmarco/src/qemu/exec.c:2439 #5 0x000055555560baa2 in cpu_physical_memory_rw (addr=3759147008, buf=0x7fffffffc1b0 "", len=4, is_write=1) at /home/elmarco/src/qemu/exec.c:2534 #6 0x000055555564c005 in cpu_physical_memory_write (addr=3759147008, buf=0x7fffffffc1b0, len=4) at /home/elmarco/src/qemu/include/exec/cpu-common.h:80 #7 0x000055555564cd9c in qtest_process_command (chr=0x55555642b890, words=0x5555578de4b0) at /home/elmarco/src/qemu/qtest.c:378 #8 0x000055555564db77 in qtest_process_inbuf (chr=0x55555642b890, inbuf=0x55555641b340) at /home/elmarco/src/qemu/qtest.c:569 #9 0x000055555564dc07 in qtest_read (opaque=0x55555642b890, buf=0x7fffffffc2e0 "writel 0xe0100800 0x0\n", size=22) at /home/elmarco/src/qemu/qtest.c:581 #10 0x000055555574ce3e in qemu_chr_be_write (s=0x55555642b890, buf=0x7fffffffc2e0 "writel 0xe0100800 0x0\n", len=22) at qemu-char.c:306 #11 0x0000555555751263 in tcp_chr_read (chan=0x55555642bcf0, cond=G_IO_IN, opaque=0x55555642b890) at qemu-char.c:2876 #12 0x00007ffff64c9a8a in g_main_context_dispatch (context=0x55555641c400) at gmain.c:3122 (without this patch, this can be reproduced with the ivshmem qtest) Implement an empty mmio write to avoid the crash. Signed-off-by: Marc-André Lureau <[email protected]> Reviewed-by: Paolo Bonzini <[email protected]> Index: xen-4.6.0-testing/tools/qemu-xen-dir-remote/hw/pci/msix.c =================================================================== --- xen-4.6.0-testing.orig/tools/qemu-xen-dir-remote/hw/pci/msix.c +++ xen-4.6.0-testing/tools/qemu-xen-dir-remote/hw/pci/msix.c @@ -200,8 +200,14 @@ static uint64_t msix_pba_mmio_read(void return pci_get_long(dev->msix_pba + addr); } +static void msix_pba_mmio_write(void *opaque, hwaddr addr, + uint64_t val, unsigned size) +{ +} + static const MemoryRegionOps msix_pba_mmio_ops = { .read = msix_pba_mmio_read, + .write = msix_pba_mmio_write, .endianness = DEVICE_LITTLE_ENDIAN, .valid = { .min_access_size = 4, ++++++ CVE-2015-8345-qemut-eepro100-infinite-loop-fix.patch ++++++ References: bsc#956832 CVE-2015-8345 From: Prasad J Pandit <address@hidden> Date: Fri, 16 Oct 2015 11:33:27 +0530 Subject: eepro100: prevent an infinite loop over same command block action_command() routine executes a chain of commands located in the Command Block List(CBL). Each Command Block(CB) has a link to the next CB in the list, given by 's->tx.link'. This is used in conjunction with the base address 's->cu_base'. An infinite loop unfolds if the 'link' to the next CB is same as the previous one, the loop ends up executing the same command over and over again. Reported-by: Qinghao Tang <address@hidden> Signed-off-by: Prasad J Pandit <address@hidden> --- hw/net/eepro100.c | 2 ++ 1 file changed, 2 insertions(+) Index: xen-4.6.0-testing/tools/qemu-xen-traditional-dir-remote/hw/eepro100.c =================================================================== --- xen-4.6.0-testing.orig/tools/qemu-xen-traditional-dir-remote/hw/eepro100.c +++ xen-4.6.0-testing/tools/qemu-xen-traditional-dir-remote/hw/eepro100.c @@ -674,6 +674,8 @@ static void eepro100_cu_command(EEPRO100 next_command: cb_address = s->cu_base + s->cu_offset; cpu_physical_memory_read(cb_address, (uint8_t *) & tx, sizeof(tx)); + if (tx.link == s->cu_offset) + break; uint16_t status = le16_to_cpu(tx.status); uint16_t command = le16_to_cpu(tx.command); logout ++++++ CVE-2015-8345-qemuu-eepro100-infinite-loop-fix.patch ++++++ References: bsc#956832 CVE-2015-8345 From: Prasad J Pandit <address@hidden> Date: Fri, 16 Oct 2015 11:33:27 +0530 Subject: eepro100: prevent an infinite loop over same command block action_command() routine executes a chain of commands located in the Command Block List(CBL). Each Command Block(CB) has a link to the next CB in the list, given by 's->tx.link'. This is used in conjunction with the base address 's->cu_base'. An infinite loop unfolds if the 'link' to the next CB is same as the previous one, the loop ends up executing the same command over and over again. Reported-by: Qinghao Tang <address@hidden> Signed-off-by: Prasad J Pandit <address@hidden> --- hw/net/eepro100.c | 2 ++ 1 file changed, 2 insertions(+) Index: xen-4.6.0-testing/tools/qemu-xen-dir-remote/hw/net/eepro100.c =================================================================== --- xen-4.6.0-testing.orig/tools/qemu-xen-dir-remote/hw/net/eepro100.c +++ xen-4.6.0-testing/tools/qemu-xen-dir-remote/hw/net/eepro100.c @@ -863,6 +863,8 @@ static void action_command(EEPRO100State uint16_t ok_status = STATUS_OK; s->cb_address = s->cu_base + s->cu_offset; read_cb(s); + if (s->tx.link == s->cu_offset) + break; bit_el = ((s->tx.command & COMMAND_EL) != 0); bit_s = ((s->tx.command & COMMAND_S) != 0); bit_i = ((s->tx.command & COMMAND_I) != 0); ++++++ CVE-2015-8504-qemut-vnc-avoid-floating-point-exception.patch ++++++ References: bsc#958493 CVE-2015-8504 Index: xen-4.5.2-testing/tools/qemu-xen-traditional-dir-remote/vnc.c =================================================================== --- xen-4.5.2-testing.orig/tools/qemu-xen-traditional-dir-remote/vnc.c +++ xen-4.5.2-testing/tools/qemu-xen-traditional-dir-remote/vnc.c @@ -1634,15 +1634,15 @@ static void set_pixel_format(VncState *v } vs->clientds = vs->serverds; - vs->clientds.pf.rmax = red_max; + vs->clientds.pf.rmax = red_max ? red_max : 0xFF; count_bits(vs->clientds.pf.rbits, red_max); vs->clientds.pf.rshift = red_shift; vs->clientds.pf.rmask = red_max << red_shift; - vs->clientds.pf.gmax = green_max; + vs->clientds.pf.gmax = green_max ? green_max : 0xFF; count_bits(vs->clientds.pf.gbits, green_max); vs->clientds.pf.gshift = green_shift; vs->clientds.pf.gmask = green_max << green_shift; - vs->clientds.pf.bmax = blue_max; + vs->clientds.pf.bmax = blue_max ? blue_max : 0xFF; count_bits(vs->clientds.pf.bbits, blue_max); vs->clientds.pf.bshift = blue_shift; vs->clientds.pf.bmask = blue_max << blue_shift; ++++++ CVE-2015-8504-qemuu-vnc-avoid-floating-point-exception.patch ++++++ References: bsc#958493 CVE-2015-8504 Index: xen-4.6.0-testing/tools/qemu-xen-dir-remote/ui/vnc.c =================================================================== --- xen-4.6.0-testing.orig/tools/qemu-xen-dir-remote/ui/vnc.c +++ xen-4.6.0-testing/tools/qemu-xen-dir-remote/ui/vnc.c @@ -2036,15 +2036,15 @@ static void set_pixel_format(VncState *v return; } - vs->client_pf.rmax = red_max; + vs->client_pf.rmax = red_max ? red_max : 0xFF; vs->client_pf.rbits = hweight_long(red_max); vs->client_pf.rshift = red_shift; vs->client_pf.rmask = red_max << red_shift; - vs->client_pf.gmax = green_max; + vs->client_pf.gmax = green_max ? green_max : 0xFF; vs->client_pf.gbits = hweight_long(green_max); vs->client_pf.gshift = green_shift; vs->client_pf.gmask = green_max << green_shift; - vs->client_pf.bmax = blue_max; + vs->client_pf.bmax = blue_max ? blue_max : 0xFF; vs->client_pf.bbits = hweight_long(blue_max); vs->client_pf.bshift = blue_shift; vs->client_pf.bmask = blue_max << blue_shift; ++++++ CVE-2015-8558-qemuu-usb-infinite-loop-in-ehci_advance_state-results-in-DoS.patch ++++++ References: bsc#959006 CVE-2015-8558 Make ehci_process_itd return an error in case we didn't do any actual iso transfer because we've found no active transaction. That'll avoid ehci happily run in circles forever if the guest builds a loop out of idts. Reported-by: Qinghao Tang <address@hidden> Tested-by: P J P <address@hidden> Signed-off-by: Gerd Hoffmann <address@hidden> --- hw/usb/hcd-ehci.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) Index: xen-4.6.0-testing/tools/qemu-xen-dir-remote/hw/usb/hcd-ehci.c =================================================================== --- xen-4.6.0-testing.orig/tools/qemu-xen-dir-remote/hw/usb/hcd-ehci.c +++ xen-4.6.0-testing/tools/qemu-xen-dir-remote/hw/usb/hcd-ehci.c @@ -1395,7 +1395,7 @@ static int ehci_process_itd(EHCIState *e { USBDevice *dev; USBEndpoint *ep; - uint32_t i, len, pid, dir, devaddr, endp; + uint32_t i, len, pid, dir, devaddr, endp, xfers = 0; uint32_t pg, off, ptr1, ptr2, max, mult; ehci->periodic_sched_active = PERIODIC_ACTIVE; @@ -1485,9 +1485,10 @@ static int ehci_process_itd(EHCIState *e ehci_raise_irq(ehci, USBSTS_INT); } itd->transact[i] &= ~ITD_XACT_ACTIVE; + xfers++; } } - return 0; + return xfers ? 0 : -1; } ++++++ CVE-2015-8568-qemuu-net-vmxnet3-avoid-memory-leakage-in-activate_device.patch ++++++ References: bsc#959386 CVE-2015-8568 >From 3ef66b01874fcc2fe3bfc73d2b61ee3a5b29fdb6 Mon Sep 17 00:00:00 2001 From: Prasad J Pandit <address@hidden> Date: Tue, 15 Dec 2015 12:17:28 +0530 Subject: [PATCH] net: vmxnet3: avoid memory leakage in activate_device Vmxnet3 device emulator does not check if the device is active before activating it, also it did not free the transmit & receive buffers while deactivating the device, thus resulting in memory leakage on the host. This patch fixes both these issues to avoid host memory leakage. Reported-by: Qinghao Tang <address@hidden> Signed-off-by: Prasad J Pandit <address@hidden> --- hw/net/vmxnet3.c | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) Index: xen-4.6.0-testing/tools/qemu-xen-dir-remote/hw/net/vmxnet3.c =================================================================== --- xen-4.6.0-testing.orig/tools/qemu-xen-dir-remote/hw/net/vmxnet3.c +++ xen-4.6.0-testing/tools/qemu-xen-dir-remote/hw/net/vmxnet3.c @@ -1135,8 +1135,13 @@ static void vmxnet3_reset_mac(VMXNET3Sta static void vmxnet3_deactivate_device(VMXNET3State *s) { - VMW_CBPRN("Deactivating vmxnet3..."); - s->device_active = false; + if (s->device_active) { + VMW_CBPRN("Deactivating vmxnet3..."); + vmxnet_tx_pkt_reset(s->tx_pkt); + vmxnet_tx_pkt_uninit(s->tx_pkt); + vmxnet_rx_pkt_uninit(s->rx_pkt); + s->device_active = false; + } } static void vmxnet3_reset(VMXNET3State *s) @@ -1145,7 +1150,6 @@ static void vmxnet3_reset(VMXNET3State * vmxnet3_deactivate_device(s); vmxnet3_reset_interrupt_states(s); - vmxnet_tx_pkt_reset(s->tx_pkt); s->drv_shmem = 0; s->tx_sop = true; s->skip_current_tx_pkt = false; @@ -1368,6 +1372,12 @@ static void vmxnet3_activate_device(VMXN return; } + /* Verify if device is active */ + if (s->device_active) { + VMW_CFPRN("Vmxnet3 device is active"); + return; + } + vmxnet3_adjust_by_guest_type(s); vmxnet3_update_features(s); vmxnet3_update_pm_state(s); @@ -1564,7 +1574,7 @@ static void vmxnet3_handle_command(VMXNE break; case VMXNET3_CMD_QUIESCE_DEV: - VMW_CBPRN("Set: VMXNET3_CMD_QUIESCE_DEV - pause the device"); + VMW_CBPRN("Set: VMXNET3_CMD_QUIESCE_DEV - deactivate the device"); vmxnet3_deactivate_device(s); break; @@ -1669,7 +1679,7 @@ vmxnet3_io_bar1_write(void *opaque, * shared address only after we get the high part */ if (val == 0) { - s->device_active = false; + vmxnet3_deactivate_device(s); } s->temp_shared_guest_driver_memory = val; s->drv_shmem = 0; @@ -1956,9 +1966,7 @@ static bool vmxnet3_peer_has_vnet_hdr(VM static void vmxnet3_net_uninit(VMXNET3State *s) { g_free(s->mcast_list); - vmxnet_tx_pkt_reset(s->tx_pkt); - vmxnet_tx_pkt_uninit(s->tx_pkt); - vmxnet_rx_pkt_uninit(s->rx_pkt); + vmxnet3_deactivate_device(s); qemu_del_nic(s->nic); } ++++++ xsa155-qemut-qdisk-double-access.patch ++++++ References: bsc#957988 >From 27942b0cb2327e93deb12326bbe7b36c81f9fa7b Mon Sep 17 00:00:00 2001 From: Stefano Stabellini <[email protected]> Date: Fri, 20 Nov 2015 10:56:00 -0500 Subject: [PATCH] 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 <[email protected]> Signed-off-by: Konrad Rzeszutek Wilk <[email protected]> --- hw/xen_blkif.h | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) Index: xen-4.6.0-testing/tools/qemu-xen-traditional-dir-remote/hw/xen_blkif.h =================================================================== --- xen-4.6.0-testing.orig/tools/qemu-xen-traditional-dir-remote/hw/xen_blkif.h +++ xen-4.6.0-testing/tools/qemu-xen-traditional-dir-remote/hw/xen_blkif.h @@ -79,8 +79,10 @@ static inline void blkif_get_x86_32_req( dst->handle = src->handle; dst->id = src->id; dst->sector_number = src->sector_number; - if (n > src->nr_segments) - n = src->nr_segments; + /* prevent the compiler from optimizing the code and using src->nr_segments instead */ + xen_mb(); + if (n > dst->nr_segments) + n = dst->nr_segments; for (i = 0; i < n; i++) dst->seg[i] = src->seg[i]; } @@ -94,8 +96,10 @@ static inline void blkif_get_x86_64_req( dst->handle = src->handle; dst->id = src->id; dst->sector_number = src->sector_number; - if (n > src->nr_segments) - n = src->nr_segments; + /* prevent the compiler from optimizing the code and using src->nr_segments instead */ + xen_mb(); + if (n > dst->nr_segments) + n = dst->nr_segments; for (i = 0; i < n; i++) dst->seg[i] = src->seg[i]; } ++++++ xsa155-qemut-xenfb.patch ++++++ References: bsc#957988 >From 0ffd4547665d2fec648ab2c9ff856c5d9db9b07c Mon Sep 17 00:00:00 2001 From: Stefano Stabellini <[email protected]> Date: Fri, 20 Nov 2015 10:37:08 -0500 Subject: [PATCH 2/2] 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 <[email protected]> --- hw/xenfb.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) Index: xen-4.6.0-testing/tools/qemu-xen-traditional-dir-remote/hw/xenfb.c =================================================================== --- xen-4.6.0-testing.orig/tools/qemu-xen-traditional-dir-remote/hw/xenfb.c +++ xen-4.6.0-testing/tools/qemu-xen-traditional-dir-remote/hw/xenfb.c @@ -827,18 +827,20 @@ static void xenfb_invalidate(void *opaqu static void xenfb_handle_events(struct XenFB *xenfb) { - uint32_t prod, cons; + uint32_t prod, cons, out_cons; struct xenfb_page *page = xenfb->c.page; prod = page->out_prod; - if (prod == page->out_cons) + out_cons = page->out_cons; + if (prod == out_cons) return; xen_rmb(); /* ensure we see ring contents up to prod */ - for (cons = page->out_cons; cons != prod; cons++) { + for (cons = out_cons; cons != prod; cons++) { union xenfb_out_event *event = &XENFB_OUT_RING_REF(page, cons); + uint8_t type = event->type; int x, y, w, h; - switch (event->type) { + switch (type) { case XENFB_TYPE_UPDATE: if (xenfb->up_count == UP_QUEUE) xenfb->up_fullscreen = 1; ++++++ xsa155-qemuu-qdisk-double-access.patch ++++++ 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 <[email protected]> Index: xen-4.6.0-testing/tools/qemu-xen-dir-remote/hw/block/xen_blkif.h =================================================================== --- xen-4.6.0-testing.orig/tools/qemu-xen-dir-remote/hw/block/xen_blkif.h +++ xen-4.6.0-testing/tools/qemu-xen-dir-remote/hw/block/xen_blkif.h @@ -85,8 +85,10 @@ static inline void blkif_get_x86_32_req( d->nr_sectors = s->nr_sectors; return; } - if (n > src->nr_segments) - n = src->nr_segments; + /* prevent the compiler from optimizing the code and using src->nr_segments instead */ + barrier(); + if (n > dst->nr_segments) + n = dst->nr_segments; for (i = 0; i < n; i++) dst->seg[i] = src->seg[i]; } @@ -106,8 +108,10 @@ static inline void blkif_get_x86_64_req( d->nr_sectors = s->nr_sectors; return; } - if (n > src->nr_segments) - n = src->nr_segments; + /* prevent the compiler from optimizing the code and using src->nr_segments instead */ + barrier(); + if (n > dst->nr_segments) + n = dst->nr_segments; for (i = 0; i < n; i++) dst->seg[i] = src->seg[i]; } ++++++ xsa155-qemuu-xenfb.patch ++++++ References: bsc#957988 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 <[email protected]> Index: xen-4.6.0-testing/tools/qemu-xen-dir-remote/hw/display/xenfb.c =================================================================== --- xen-4.6.0-testing.orig/tools/qemu-xen-dir-remote/hw/display/xenfb.c +++ xen-4.6.0-testing/tools/qemu-xen-dir-remote/hw/display/xenfb.c @@ -779,18 +779,20 @@ static void xenfb_invalidate(void *opaqu static void xenfb_handle_events(struct XenFB *xenfb) { - uint32_t prod, cons; + uint32_t prod, cons, out_cons; struct xenfb_page *page = xenfb->c.page; prod = page->out_prod; - if (prod == page->out_cons) + out_cons = page->out_cons; + if (prod == out_cons) return; xen_rmb(); /* ensure we see ring contents up to prod */ - for (cons = page->out_cons; cons != prod; cons++) { + for (cons = out_cons; cons != prod; cons++) { union xenfb_out_event *event = &XENFB_OUT_RING_REF(page, cons); + uint8_t type = event->type; int x, y, w, h; - switch (event->type) { + switch (type) { case XENFB_TYPE_UPDATE: if (xenfb->up_count == UP_QUEUE) xenfb->up_fullscreen = 1; ++++++ xsa155-xen-0001-xen-Add-RING_COPY_REQUEST.patch ++++++ References: bsc#957988 >From 12b11658a9d6a654a1e7acbf2f2d56ce9a396c86 Mon Sep 17 00:00:00 2001 From: David Vrabel <[email protected]> Date: Fri, 20 Nov 2015 11:59:05 -0500 Subject: [PATCH 1/3] 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 <[email protected]> Signed-off-by: Konrad Rzeszutek Wilk <[email protected]> --- v2: Add comment about GCC bug. --- xen/include/public/io/ring.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) Index: xen-4.6.0-testing/xen/include/public/io/ring.h =================================================================== --- xen-4.6.0-testing.orig/xen/include/public/io/ring.h +++ xen-4.6.0-testing/xen/include/public/io/ring.h @@ -212,6 +212,20 @@ typedef struct __name##_back_ring __name #define RING_GET_REQUEST(_r, _idx) \ (&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].req)) +/* + * Get a local copy of a request. + * + * Use this in preference to RING_GET_REQUEST() so all processing is + * done on a local copy that cannot be modified by the other end. + * + * Note that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 may cause this + * to be ineffective where _req is a struct which consists of only bitfields. + */ +#define RING_COPY_REQUEST(_r, _idx, _req) do { \ + /* Use volatile to force the copy into _req. */ \ + *(_req) = *(volatile typeof(_req))RING_GET_REQUEST(_r, _idx); \ +} while (0) + #define RING_GET_RESPONSE(_r, _idx) \ (&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].rsp)) ++++++ xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch ++++++ References: bsc#957988 >From 851ffb4eea917e2708c912291dea4d133026c0ac Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk <[email protected]> Date: Fri, 20 Nov 2015 12:16:02 -0500 Subject: [PATCH 2/3] 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 <[email protected]> --- v2: Fix compile issues with tapdisk-vbd --- tools/blktap2/drivers/block-log.c | 3 ++- tools/blktap2/drivers/tapdisk-vbd.c | 8 ++++---- 2 files changed, 6 insertions(+), 5 deletions(-) Index: xen-4.6.0-testing/tools/blktap2/drivers/block-log.c =================================================================== --- xen-4.6.0-testing.orig/tools/blktap2/drivers/block-log.c +++ xen-4.6.0-testing/tools/blktap2/drivers/block-log.c @@ -494,11 +494,12 @@ static int ctl_kick(struct tdlog_state* reqstart = s->bring.req_cons; reqend = s->sring->req_prod; + xen_mb(); BDPRINTF("ctl: ring kicked (start = %u, end = %u)", reqstart, reqend); while (reqstart != reqend) { /* XXX actually submit these! */ - memcpy(&req, RING_GET_REQUEST(&s->bring, reqstart), sizeof(req)); + RING_COPY_REQUEST(&s->bring, reqstart, &req); BDPRINTF("ctl: read request %"PRIu64":%u", req.sector, req.count); s->bring.req_cons = ++reqstart; Index: xen-4.6.0-testing/tools/blktap2/drivers/tapdisk-vbd.c =================================================================== --- xen-4.6.0-testing.orig/tools/blktap2/drivers/tapdisk-vbd.c +++ xen-4.6.0-testing/tools/blktap2/drivers/tapdisk-vbd.c @@ -1555,7 +1555,7 @@ tapdisk_vbd_pull_ring_requests(td_vbd_t int idx; RING_IDX rp, rc; td_ring_t *ring; - blkif_request_t *req; + blkif_request_t req; td_vbd_request_t *vreq; ring = &vbd->ring; @@ -1566,16 +1566,16 @@ tapdisk_vbd_pull_ring_requests(td_vbd_t xen_rmb(); for (rc = ring->fe_ring.req_cons; rc != rp; rc++) { - req = RING_GET_REQUEST(&ring->fe_ring, rc); + RING_COPY_REQUEST(&ring->fe_ring, rc, &req); ++ring->fe_ring.req_cons; - idx = req->id; + idx = req.id; vreq = &vbd->request_list[idx]; ASSERT(list_empty(&vreq->next)); ASSERT(vreq->secs_pending == 0); - memcpy(&vreq->req, req, sizeof(blkif_request_t)); + memcpy(&vreq->req, &req, sizeof(blkif_request_t)); vbd->received++; vreq->vbd = vbd; ++++++ xsa155-xen-0003-libvchan-Read-prod-cons-only-once.patch ++++++ >From c1fce65e2b720684ea6ba76ae59921542bd154bb Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk <[email protected]> Date: Fri, 20 Nov 2015 12:22:14 -0500 Subject: [PATCH 3/3] 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 <[email protected]> --- tools/libvchan/io.c | 2 ++ 1 file changed, 2 insertions(+) Index: xen-4.6.0-testing/tools/libvchan/io.c =================================================================== --- xen-4.6.0-testing.orig/tools/libvchan/io.c +++ xen-4.6.0-testing/tools/libvchan/io.c @@ -117,6 +117,7 @@ static inline int send_notify(struct lib static inline int raw_get_data_ready(struct libxenvchan *ctrl) { uint32_t ready = rd_prod(ctrl) - rd_cons(ctrl); + xen_mb(); /* Ensure 'ready' is read only once. */ if (ready > rd_ring_size(ctrl)) /* We have no way to return errors. Locking up the ring is * better than the alternatives. */ @@ -158,6 +159,7 @@ int libxenvchan_data_ready(struct libxen static inline int raw_get_buffer_space(struct libxenvchan *ctrl) { uint32_t ready = wr_ring_size(ctrl) - (wr_prod(ctrl) - wr_cons(ctrl)); + xen_mb(); /* Ensure 'ready' is read only once. */ if (ready > wr_ring_size(ctrl)) /* We have no way to return errors. Locking up the ring is * better than the alternatives. */ ++++++ xsa159.patch ++++++ memory: fix XENMEM_exchange error handling assign_pages() can fail due to the domain getting killed in parallel, which should not result in a hypervisor crash. Also delete a redundant put_gfn() - all relevant paths leading to the "fail" label already do this (and there are also paths where it was plain wrong). All of the put_gfn()-s got introduced by 51032ca058 ("Modify naming of queries into the p2m"), including the otherwise unneeded initializer for k (with even a kind of misleading comment - the compiler warning could actually have served as a hint that the use is wrong). This is XSA-159. Signed-off-by: Jan Beulich <[email protected]> Acked-by: Ian Campbell <[email protected]> Index: xen-4.6.0-testing/xen/common/memory.c =================================================================== --- xen-4.6.0-testing.orig/xen/common/memory.c +++ xen-4.6.0-testing/xen/common/memory.c @@ -328,7 +328,7 @@ static long memory_exchange(XEN_GUEST_HA PAGE_LIST_HEAD(out_chunk_list); unsigned long in_chunk_order, out_chunk_order; xen_pfn_t gpfn, gmfn, mfn; - unsigned long i, j, k = 0; /* gcc ... */ + unsigned long i, j, k; unsigned int memflags = 0; long rc = 0; struct domain *d; @@ -566,11 +566,12 @@ static long memory_exchange(XEN_GUEST_HA fail: /* Reassign any input pages we managed to steal. */ while ( (page = page_list_remove_head(&in_chunk_list)) ) - { - put_gfn(d, gmfn + k--); if ( assign_pages(d, page, 0, MEMF_no_refcount) ) - BUG(); - } + { + BUG_ON(!d->is_dying); + if ( test_and_clear_bit(_PGC_allocated, &page->count_info) ) + put_page(page); + } dying: rcu_unlock_domain(d); ++++++ xsa160.patch ++++++ >From adcbd15b1aec8367f790774c998db199c9b577bf Mon Sep 17 00:00:00 2001 From: Ian Jackson <[email protected]> Date: Wed, 18 Nov 2015 15:34:54 +0000 Subject: [PATCH] libxl: Fix bootloader-related virtual memory leak on pv build failure The bootloader may call libxl__file_reference_map(), which mmap's the pv_kernel and pv_ramdisk into process memory. This was only unmapped, however, on the success path of libxl__build_pv(). If there were a failure anywhere between libxl_bootloader.c:parse_bootloader_result() and the end of libxl__build_pv(), the calls to libxl__file_reference_unmap() would be skipped, leaking the mapped virtual memory. Ideally this would be fixed by adding the unmap calls to the destruction path for libxl__domain_build_state. Unfortunately the lifetime of the libxl__domain_build_state is opaque, and it doesn't have a proper destruction path. But, the only thing in it that isn't from the gc are these bootloader references, and they are only ever set for one libxl__domain_build_state, the one which is libxl__domain_create_state.build_state. So we can clean up in the exit path from libxl__domain_create_*, which always comes through domcreate_complete. Remove the now-redundant unmaps in libxl__build_pv's success path. This is XSA-160. Acked-by: Ian Campbell <[email protected]> --- tools/libxl/libxl_create.c | 3 +++ tools/libxl/libxl_dom.c | 3 --- 2 files changed, 3 insertions(+), 3 deletions(-) Index: xen-4.6.0-testing/tools/libxl/libxl_create.c =================================================================== --- xen-4.6.0-testing.orig/tools/libxl/libxl_create.c +++ xen-4.6.0-testing/tools/libxl/libxl_create.c @@ -1484,6 +1484,9 @@ static void domcreate_complete(libxl__eg libxl_domain_config *const d_config = dcs->guest_config; libxl_domain_config *d_config_saved = &dcs->guest_config_saved; + libxl__file_reference_unmap(&dcs->build_state.pv_kernel); + libxl__file_reference_unmap(&dcs->build_state.pv_ramdisk); + if (!rc && d_config->b_info.exec_ssidref) rc = xc_flask_relabel_domain(CTX->xch, dcs->guest_domid, d_config->b_info.exec_ssidref); Index: xen-4.6.0-testing/tools/libxl/libxl_dom.c =================================================================== --- xen-4.6.0-testing.orig/tools/libxl/libxl_dom.c +++ xen-4.6.0-testing/tools/libxl/libxl_dom.c @@ -750,9 +750,6 @@ int libxl__build_pv(libxl__gc *gc, uint3 state->store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn); } - libxl__file_reference_unmap(&state->pv_kernel); - libxl__file_reference_unmap(&state->pv_ramdisk); - ret = 0; out: xc_dom_release(dom); ++++++ xsa162-qemut.patch ++++++ net: pcnet: add check to validate receive data size(CVE-2015-7504) In loopback mode, pcnet_receive routine appends CRC code to the receive buffer. If the data size given is same as the buffer size, the appended CRC code overwrites 4 bytes after s->buffer. Added a check to avoid that. --- hw/net/pcnet.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) Index: xen-4.5.2-testing/tools/qemu-xen-traditional-dir-remote/hw/pcnet.c =================================================================== --- xen-4.5.2-testing.orig/tools/qemu-xen-traditional-dir-remote/hw/pcnet.c +++ xen-4.5.2-testing/tools/qemu-xen-traditional-dir-remote/hw/pcnet.c @@ -1153,7 +1153,7 @@ static void pcnet_receive(void *opaque, uint32_t fcs = ~0; uint8_t *p = src; - while (p != &src[size-4]) + while (p != &src[size]) CRC(fcs, *p++); crc_err = (*(uint32_t *)p != htonl(fcs)); } @@ -1284,12 +1284,13 @@ static void pcnet_transmit(PCNetState *s bcnt = 4096 - GET_FIELD(tmd.length, TMDL, BCNT); /* if multi-tmd packet outsizes s->buffer then skip it silently. - Note: this is not what real hw does */ - if (s->xmit_pos + bcnt > sizeof(s->buffer)) { - s->xmit_pos = -1; - goto txdone; + * Note: this is not what real hw does. + * Last four bytes of s->buffer are used to store CRC FCS code. + */ + if (s->xmit_pos + bcnt > sizeof(s->buffer) - 4) { + s->xmit_pos = -1; + goto txdone; } - s->phys_mem_read(s->dma_opaque, PHYSADDR(s, tmd.tbadr), s->buffer + s->xmit_pos, bcnt, CSR_BSWP(s)); s->xmit_pos += bcnt; ++++++ xsa162-qemuu.patch ++++++ net: pcnet: add check to validate receive data size(CVE-2015-7504) In loopback mode, pcnet_receive routine appends CRC code to the receive buffer. If the data size given is same as the buffer size, the appended CRC code overwrites 4 bytes after s->buffer. Added a check to avoid that. --- hw/net/pcnet.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) Index: xen-4.6.0-testing/tools/qemu-xen-dir-remote/hw/net/pcnet.c =================================================================== --- xen-4.6.0-testing.orig/tools/qemu-xen-dir-remote/hw/net/pcnet.c +++ xen-4.6.0-testing/tools/qemu-xen-dir-remote/hw/net/pcnet.c @@ -1106,7 +1106,7 @@ ssize_t pcnet_receive(NetClientState *nc uint32_t fcs = ~0; uint8_t *p = src; - while (p != &src[size-4]) + while (p != &src[size]) CRC(fcs, *p++); crc_err = (*(uint32_t *)p != htonl(fcs)); } @@ -1255,8 +1255,10 @@ static void pcnet_transmit(PCNetState *s bcnt = 4096 - GET_FIELD(tmd.length, TMDL, BCNT); /* if multi-tmd packet outsizes s->buffer then skip it silently. - Note: this is not what real hw does */ - if (s->xmit_pos + bcnt > sizeof(s->buffer)) { + * Note: this is not what real hw does. + * Last four bytes of s->buffer are used to store CRC FCS code. + */ + if (s->xmit_pos + bcnt > sizeof(s->buffer) - 4) { s->xmit_pos = -1; goto txdone; } ++++++ xsa164.patch ++++++ References: bsc#958007 XSA-164 MSI-X: avoid array overrun upon MSI-X table writes pt_msix_init() allocates msix->msix_entry[] to just cover msix->total_entries entries. While pci_msix_readl() resorts to reading physical memory for out of bounds reads, pci_msix_writel() so far simply accessed/corrupted unrelated memory. pt_iomem_map()'s call to cpu_register_physical_memory() registers a page granular region, which is necessary as the Pending Bit Array may share space with the MSI-X table (but nothing else is allowed to). This also explains why pci_msix_readl() actually honors out of bounds reads, but pci_msi_writel() doesn't need to. This is XSA-164. Signed-off-by: Jan Beulich <[email protected]> Index: xen-4.6.0-testing/tools/qemu-xen-traditional-dir-remote/hw/pt-msi.c =================================================================== --- xen-4.6.0-testing.orig/tools/qemu-xen-traditional-dir-remote/hw/pt-msi.c +++ xen-4.6.0-testing/tools/qemu-xen-traditional-dir-remote/hw/pt-msi.c @@ -440,6 +440,13 @@ static void pci_msix_writel(void *opaque return; } + if ( addr - msix->mmio_base_addr >= msix->total_entries * 16 ) + { + PT_LOG("Error: Out of bounds write to MSI-X table," + " addr %016"PRIx64"\n", addr); + return; + } + entry_nr = (addr - msix->mmio_base_addr) / 16; entry = &msix->msix_entry[entry_nr]; offset = ((addr - msix->mmio_base_addr) % 16) / 4; ++++++ xsa165.patch ++++++ x86: don't leak ST(n)/XMMn values to domains first using them FNINIT doesn't alter these registers, and hence using it is insufficient to initialize a guest's initial state. This is XSA-165. Signed-off-by: Jan Beulich <[email protected]> Reviewed-by: Andrew Cooper <[email protected]> Index: xen-4.6.0-testing/xen/arch/x86/domain.c =================================================================== --- xen-4.6.0-testing.orig/xen/arch/x86/domain.c +++ xen-4.6.0-testing/xen/arch/x86/domain.c @@ -851,6 +851,17 @@ int arch_set_info_guest( if ( v->arch.xsave_area ) v->arch.xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE; } + else if ( v->arch.xsave_area ) + memset(&v->arch.xsave_area->xsave_hdr, 0, + sizeof(v->arch.xsave_area->xsave_hdr)); + else + { + typeof(v->arch.xsave_area->fpu_sse) *fpu_sse = v->arch.fpu_ctxt; + + memset(fpu_sse, 0, sizeof(*fpu_sse)); + fpu_sse->fcw = FCW_DEFAULT; + fpu_sse->mxcsr = MXCSR_DEFAULT; + } if ( !compat ) { Index: xen-4.6.0-testing/xen/arch/x86/i387.c =================================================================== --- xen-4.6.0-testing.orig/xen/arch/x86/i387.c +++ xen-4.6.0-testing/xen/arch/x86/i387.c @@ -17,19 +17,6 @@ #include <asm/xstate.h> #include <asm/asm_defns.h> -static void fpu_init(void) -{ - unsigned long val; - - asm volatile ( "fninit" ); - if ( cpu_has_xmm ) - { - /* load default value into MXCSR control/status register */ - val = MXCSR_DEFAULT; - asm volatile ( "ldmxcsr %0" : : "m" (val) ); - } -} - /*******************************/ /* FPU Restore Functions */ /*******************************/ @@ -248,15 +235,8 @@ void vcpu_restore_fpu_lazy(struct vcpu * if ( cpu_has_xsave ) fpu_xrstor(v, XSTATE_LAZY); - else if ( v->fpu_initialised ) - { - if ( cpu_has_fxsr ) - fpu_fxrstor(v); - else - fpu_frstor(v); - } else - fpu_init(); + fpu_fxrstor(v); v->fpu_initialised = 1; v->fpu_dirtied = 1; @@ -313,7 +293,14 @@ int vcpu_init_fpu(struct vcpu *v) else { v->arch.fpu_ctxt = _xzalloc(sizeof(v->arch.xsave_area->fpu_sse), 16); - if ( !v->arch.fpu_ctxt ) + if ( v->arch.fpu_ctxt ) + { + typeof(v->arch.xsave_area->fpu_sse) *fpu_sse = v->arch.fpu_ctxt; + + fpu_sse->fcw = FCW_DEFAULT; + fpu_sse->mxcsr = MXCSR_DEFAULT; + } + else rc = -ENOMEM; } ++++++ xsa166.patch ++++++ x86/HVM: avoid reading ioreq state more than once Otherwise, especially when the compiler chooses to translate the switch() to a jump table, unpredictable behavior (and in the jump table case arbitrary code execution) can result. This is XSA-166. Signed-off-by: Jan Beulich <[email protected]> Acked-by: Ian Campbell <[email protected]> Index: xen-4.6.0-testing/xen/arch/x86/hvm/hvm.c =================================================================== --- xen-4.6.0-testing.orig/xen/arch/x86/hvm/hvm.c +++ xen-4.6.0-testing/xen/arch/x86/hvm/hvm.c @@ -448,7 +448,10 @@ static bool_t hvm_wait_for_io(struct hvm { while ( sv->pending ) { - switch ( p->state ) + unsigned int state = p->state; + + rmb(); + switch ( state ) { case STATE_IOREQ_NONE: /* @@ -459,18 +462,15 @@ static bool_t hvm_wait_for_io(struct hvm hvm_io_assist(sv, ~0ul); break; case STATE_IORESP_READY: /* IORESP_READY -> NONE */ - rmb(); /* see IORESP_READY /then/ read contents of ioreq */ p->state = STATE_IOREQ_NONE; hvm_io_assist(sv, p->data); break; case STATE_IOREQ_READY: /* IOREQ_{READY,INPROCESS} -> IORESP_READY */ case STATE_IOREQ_INPROCESS: - wait_on_xen_event_channel(sv->ioreq_evtchn, - (p->state != STATE_IOREQ_READY) && - (p->state != STATE_IOREQ_INPROCESS)); + wait_on_xen_event_channel(sv->ioreq_evtchn, p->state != state); break; default: - gdprintk(XENLOG_ERR, "Weird HVM iorequest state %d.\n", p->state); + gdprintk(XENLOG_ERR, "Weird HVM iorequest state %u\n", state); sv->pending = 0; domain_crash(sv->vcpu->domain); return 0; /* bail */
