From 8292994238889b5c8f2887fa8ddaa94b4f423683fdd1447701fd14f9cbd6440c Mon Sep 17 00:00:00 2001 From: Charles Arnold Date: Mon, 4 Jan 2016 22:25:00 +0000 Subject: [PATCH] - 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 - 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 - 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 OBS-URL: https://build.opensuse.org/package/show/Virtualization/xen?expand=0&rev=393 --- ...o-emulated-disk-driver-for-xvdX-disk.patch | 31 ++++++ ...only-check-introduced-by-XSA-142-fix.patch | 105 ++++++++++++++++++ ...f24-x86-vPMU-document-as-unsupported.patch | 25 +++++ ...t-consistent-in-hvm_set_callback_via.patch | 40 +++++++ ...u-pci-null-pointer-dereference-issue.patch | 53 +++++++++ ...345-qemut-eepro100-infinite-loop-fix.patch | 34 ++++++ ...345-qemuu-eepro100-infinite-loop-fix.patch | 34 ++++++ ...t-vnc-avoid-floating-point-exception.patch | 25 +++++ ...u-vnc-avoid-floating-point-exception.patch | 25 +++++ ...in-ehci_advance_state-results-in-DoS.patch | 39 +++++++ ...id-memory-leakage-in-activate_device.patch | 89 +++++++++++++++ xen.changes | 80 +++++++++++++ xen.spec | 78 ++++++++++--- xsa155-qemut-qdisk-double-access.patch | 52 +++++++++ xsa155-qemut-xenfb.patch | 49 ++++++++ xsa155-qemuu-qdisk-double-access.patch | 43 +++++++ xsa155-qemuu-xenfb.patch | 43 +++++++ ...5-xen-0001-xen-Add-RING_COPY_REQUEST.patch | 55 +++++++++ ...n-0002-blktap2-Use-RING_COPY_REQUEST.patch | 74 ++++++++++++ ...03-libvchan-Read-prod-cons-only-once.patch | 38 +++++++ xsa159.patch | 48 ++++++++ xsa160.patch | 63 +++++++++++ xsa162-qemut.patch | 43 +++++++ xsa162-qemuu.patch | 37 ++++++ xsa164.patch | 37 ++++++ xsa165.patch | 89 +++++++++++++++ xsa166.patch | 48 ++++++++ 27 files changed, 1363 insertions(+), 14 deletions(-) create mode 100644 5628fc67-libxl-No-emulated-disk-driver-for-xvdX-disk.patch create mode 100644 5649bcbe-libxl-relax-readonly-check-introduced-by-XSA-142-fix.patch create mode 100644 56549f24-x86-vPMU-document-as-unsupported.patch create mode 100644 5677f350-x86-make-debug-output-consistent-in-hvm_set_callback_via.patch create mode 100644 CVE-2015-7549-qemuu-pci-null-pointer-dereference-issue.patch create mode 100644 CVE-2015-8345-qemut-eepro100-infinite-loop-fix.patch create mode 100644 CVE-2015-8345-qemuu-eepro100-infinite-loop-fix.patch create mode 100644 CVE-2015-8504-qemut-vnc-avoid-floating-point-exception.patch create mode 100644 CVE-2015-8504-qemuu-vnc-avoid-floating-point-exception.patch create mode 100644 CVE-2015-8558-qemuu-usb-infinite-loop-in-ehci_advance_state-results-in-DoS.patch create mode 100644 CVE-2015-8568-qemuu-net-vmxnet3-avoid-memory-leakage-in-activate_device.patch create mode 100644 xsa155-qemut-qdisk-double-access.patch create mode 100644 xsa155-qemut-xenfb.patch create mode 100644 xsa155-qemuu-qdisk-double-access.patch create mode 100644 xsa155-qemuu-xenfb.patch create mode 100644 xsa155-xen-0001-xen-Add-RING_COPY_REQUEST.patch create mode 100644 xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch create mode 100644 xsa155-xen-0003-libvchan-Read-prod-cons-only-once.patch create mode 100644 xsa159.patch create mode 100644 xsa160.patch create mode 100644 xsa162-qemut.patch create mode 100644 xsa162-qemuu.patch create mode 100644 xsa164.patch create mode 100644 xsa165.patch create mode 100644 xsa166.patch diff --git a/5628fc67-libxl-No-emulated-disk-driver-for-xvdX-disk.patch b/5628fc67-libxl-No-emulated-disk-driver-for-xvdX-disk.patch new file mode 100644 index 0000000..0d98633 --- /dev/null +++ b/5628fc67-libxl-No-emulated-disk-driver-for-xvdX-disk.patch @@ -0,0 +1,31 @@ +Subject: libxl: No emulated disk driver for xvdX disk +From: Anthony PERARD anthony.perard@citrix.com 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 +Acked-by: Ian Jackson + +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", diff --git a/5649bcbe-libxl-relax-readonly-check-introduced-by-XSA-142-fix.patch b/5649bcbe-libxl-relax-readonly-check-introduced-by-XSA-142-fix.patch new file mode 100644 index 0000000..7833ace --- /dev/null +++ b/5649bcbe-libxl-relax-readonly-check-introduced-by-XSA-142-fix.patch @@ -0,0 +1,105 @@ +Subject: libxl: relax readonly check introduced by XSA-142 fix +From: Jim Fehlig jfehlig@suse.com 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 +Acked-by: Stefano Stabellini +Acked-by: Ian Campbell + +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"); diff --git a/56549f24-x86-vPMU-document-as-unsupported.patch b/56549f24-x86-vPMU-document-as-unsupported.patch new file mode 100644 index 0000000..7097986 --- /dev/null +++ b/56549f24-x86-vPMU-document-as-unsupported.patch @@ -0,0 +1,25 @@ +# Commit c03480cf5c4e96fb4afb2237ad0a3cac7162564a +# Date 2015-11-24 18:32:20 +0100 +# Author Jan Beulich +# Committer Jan Beulich +x86/vPMU: document as unsupported + +This is XSA-163. + +Signed-off-by: Jan Beulich + +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 | ` diff --git a/5677f350-x86-make-debug-output-consistent-in-hvm_set_callback_via.patch b/5677f350-x86-make-debug-output-consistent-in-hvm_set_callback_via.patch new file mode 100644 index 0000000..dffe6db --- /dev/null +++ b/5677f350-x86-make-debug-output-consistent-in-hvm_set_callback_via.patch @@ -0,0 +1,40 @@ +Reference: bsc#960093 CVE-2015-8615 XSA-169 + +Subject: x86: make debug output consistent in hvm_set_callback_via +From: Malcolm Crossley malcolm.crossley@citrix.com 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 +Reviewed-by: Jan Beulich +Acked-by: Ian Campbell + +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) diff --git a/CVE-2015-7549-qemuu-pci-null-pointer-dereference-issue.patch b/CVE-2015-7549-qemuu-pci-null-pointer-dereference-issue.patch new file mode 100644 index 0000000..307fa68 --- /dev/null +++ b/CVE-2015-7549-qemuu-pci-null-pointer-dereference-issue.patch @@ -0,0 +1,53 @@ +References: bsc#958918 CVE-2015-7549 + +Subject: msix: implement pba write (but read-only) +From: Marc-André Lureau marcandre.lureau@redhat.com 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 , 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 , 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 +Reviewed-by: Paolo Bonzini + +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, diff --git a/CVE-2015-8345-qemut-eepro100-infinite-loop-fix.patch b/CVE-2015-8345-qemut-eepro100-infinite-loop-fix.patch new file mode 100644 index 0000000..6902981 --- /dev/null +++ b/CVE-2015-8345-qemut-eepro100-infinite-loop-fix.patch @@ -0,0 +1,34 @@ +References: bsc#956832 CVE-2015-8345 + +From: Prasad J Pandit +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 +Signed-off-by: Prasad J Pandit +--- + 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 diff --git a/CVE-2015-8345-qemuu-eepro100-infinite-loop-fix.patch b/CVE-2015-8345-qemuu-eepro100-infinite-loop-fix.patch new file mode 100644 index 0000000..a366d63 --- /dev/null +++ b/CVE-2015-8345-qemuu-eepro100-infinite-loop-fix.patch @@ -0,0 +1,34 @@ +References: bsc#956832 CVE-2015-8345 + +From: Prasad J Pandit +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 +Signed-off-by: Prasad J Pandit +--- + 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); diff --git a/CVE-2015-8504-qemut-vnc-avoid-floating-point-exception.patch b/CVE-2015-8504-qemut-vnc-avoid-floating-point-exception.patch new file mode 100644 index 0000000..d358c5e --- /dev/null +++ b/CVE-2015-8504-qemut-vnc-avoid-floating-point-exception.patch @@ -0,0 +1,25 @@ +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; diff --git a/CVE-2015-8504-qemuu-vnc-avoid-floating-point-exception.patch b/CVE-2015-8504-qemuu-vnc-avoid-floating-point-exception.patch new file mode 100644 index 0000000..e587283 --- /dev/null +++ b/CVE-2015-8504-qemuu-vnc-avoid-floating-point-exception.patch @@ -0,0 +1,25 @@ +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; diff --git a/CVE-2015-8558-qemuu-usb-infinite-loop-in-ehci_advance_state-results-in-DoS.patch b/CVE-2015-8558-qemuu-usb-infinite-loop-in-ehci_advance_state-results-in-DoS.patch new file mode 100644 index 0000000..87bdd14 --- /dev/null +++ b/CVE-2015-8558-qemuu-usb-infinite-loop-in-ehci_advance_state-results-in-DoS.patch @@ -0,0 +1,39 @@ +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 +Tested-by: P J P +Signed-off-by: Gerd Hoffmann +--- + 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; + } + + diff --git a/CVE-2015-8568-qemuu-net-vmxnet3-avoid-memory-leakage-in-activate_device.patch b/CVE-2015-8568-qemuu-net-vmxnet3-avoid-memory-leakage-in-activate_device.patch new file mode 100644 index 0000000..40fb469 --- /dev/null +++ b/CVE-2015-8568-qemuu-net-vmxnet3-avoid-memory-leakage-in-activate_device.patch @@ -0,0 +1,89 @@ +References: bsc#959386 CVE-2015-8568 + +From 3ef66b01874fcc2fe3bfc73d2b61ee3a5b29fdb6 Mon Sep 17 00:00:00 2001 +From: Prasad J Pandit +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 +Signed-off-by: Prasad J Pandit +--- +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); + } + diff --git a/xen.changes b/xen.changes index b7d99c1..11e4b3d 100644 --- a/xen.changes +++ b/xen.changes @@ -1,3 +1,10 @@ +------------------------------------------------------------------- +Mon Jan 4 11:32:10 MST 2016 - carnold@suse.com + +- 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 + ------------------------------------------------------------------- Mon Dec 21 09:09:55 UTC 2015 - ohering@suse.de @@ -5,6 +12,79 @@ Mon Dec 21 09:09:55 UTC 2015 - ohering@suse.de instead of proc-xen.mount to workaround a bug in systemd "design" (bnc#959845) +------------------------------------------------------------------- +Wed Dec 16 12:16:21 MST 2015 - carnold@suse.com + +- 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 - carnold@suse.com + +- 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 - carnold@suse.com + +- 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 - carnold@suse.com + +- 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 + ------------------------------------------------------------------- Tue Nov 24 08:44:57 MST 2015 - carnold@suse.com diff --git a/xen.spec b/xen.spec index bec9726..ff0cb2d 100644 --- a/xen.spec +++ b/xen.spec @@ -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 @@ BuildRequires: xorg-x11-util-devel %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 @@ Patch3: 561bbc8b-VT-d-don-t-suppress-invalidation-address-write-when-it- 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 @@ Patch259: CVE-2015-4037-qemuu-smb-config-dir-name.patch 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 @@ Authors: %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 @@ Authors: %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 diff --git a/xsa155-qemut-qdisk-double-access.patch b/xsa155-qemut-qdisk-double-access.patch new file mode 100644 index 0000000..64169a7 --- /dev/null +++ b/xsa155-qemut-qdisk-double-access.patch @@ -0,0 +1,52 @@ +References: bsc#957988 + +From 27942b0cb2327e93deb12326bbe7b36c81f9fa7b Mon Sep 17 00:00:00 2001 +From: Stefano Stabellini +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 +Signed-off-by: Konrad Rzeszutek Wilk +--- + 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]; + } diff --git a/xsa155-qemut-xenfb.patch b/xsa155-qemut-xenfb.patch new file mode 100644 index 0000000..3c81ec8 --- /dev/null +++ b/xsa155-qemut-xenfb.patch @@ -0,0 +1,49 @@ +References: bsc#957988 + +From 0ffd4547665d2fec648ab2c9ff856c5d9db9b07c Mon Sep 17 00:00:00 2001 +From: Stefano Stabellini +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 +--- + 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; diff --git a/xsa155-qemuu-qdisk-double-access.patch b/xsa155-qemuu-qdisk-double-access.patch new file mode 100644 index 0000000..1bc2329 --- /dev/null +++ b/xsa155-qemuu-qdisk-double-access.patch @@ -0,0 +1,43 @@ +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 + +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]; + } diff --git a/xsa155-qemuu-xenfb.patch b/xsa155-qemuu-xenfb.patch new file mode 100644 index 0000000..1793506 --- /dev/null +++ b/xsa155-qemuu-xenfb.patch @@ -0,0 +1,43 @@ +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 + + +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; diff --git a/xsa155-xen-0001-xen-Add-RING_COPY_REQUEST.patch b/xsa155-xen-0001-xen-Add-RING_COPY_REQUEST.patch new file mode 100644 index 0000000..3437854 --- /dev/null +++ b/xsa155-xen-0001-xen-Add-RING_COPY_REQUEST.patch @@ -0,0 +1,55 @@ +References: bsc#957988 + +From 12b11658a9d6a654a1e7acbf2f2d56ce9a396c86 Mon Sep 17 00:00:00 2001 +From: David Vrabel +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 +Signed-off-by: Konrad Rzeszutek Wilk +--- +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)) + diff --git a/xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch b/xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch new file mode 100644 index 0000000..d0b4eb2 --- /dev/null +++ b/xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch @@ -0,0 +1,74 @@ +References: bsc#957988 + +From 851ffb4eea917e2708c912291dea4d133026c0ac Mon Sep 17 00:00:00 2001 +From: Konrad Rzeszutek Wilk +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 + +--- +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; + diff --git a/xsa155-xen-0003-libvchan-Read-prod-cons-only-once.patch b/xsa155-xen-0003-libvchan-Read-prod-cons-only-once.patch new file mode 100644 index 0000000..6827e78 --- /dev/null +++ b/xsa155-xen-0003-libvchan-Read-prod-cons-only-once.patch @@ -0,0 +1,38 @@ +From c1fce65e2b720684ea6ba76ae59921542bd154bb Mon Sep 17 00:00:00 2001 +From: Konrad Rzeszutek Wilk +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 +--- + 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. */ diff --git a/xsa159.patch b/xsa159.patch new file mode 100644 index 0000000..2353e1d --- /dev/null +++ b/xsa159.patch @@ -0,0 +1,48 @@ +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 +Acked-by: Ian Campbell + +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); diff --git a/xsa160.patch b/xsa160.patch new file mode 100644 index 0000000..56f5aad --- /dev/null +++ b/xsa160.patch @@ -0,0 +1,63 @@ +From adcbd15b1aec8367f790774c998db199c9b577bf Mon Sep 17 00:00:00 2001 +From: Ian Jackson +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 +--- + 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); diff --git a/xsa162-qemut.patch b/xsa162-qemut.patch new file mode 100644 index 0000000..26d9a75 --- /dev/null +++ b/xsa162-qemut.patch @@ -0,0 +1,43 @@ +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; diff --git a/xsa162-qemuu.patch b/xsa162-qemuu.patch new file mode 100644 index 0000000..b98b2b1 --- /dev/null +++ b/xsa162-qemuu.patch @@ -0,0 +1,37 @@ +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; + } diff --git a/xsa164.patch b/xsa164.patch new file mode 100644 index 0000000..0ad2714 --- /dev/null +++ b/xsa164.patch @@ -0,0 +1,37 @@ +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 + +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; diff --git a/xsa165.patch b/xsa165.patch new file mode 100644 index 0000000..8692b01 --- /dev/null +++ b/xsa165.patch @@ -0,0 +1,89 @@ +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 +Reviewed-by: Andrew Cooper + +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 + #include + +-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; + } + diff --git a/xsa166.patch b/xsa166.patch new file mode 100644 index 0000000..56bf4a0 --- /dev/null +++ b/xsa166.patch @@ -0,0 +1,48 @@ +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 +Acked-by: Ian Campbell + +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 */