pool/xen
SHA256
2
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

- bsc#960093 - VUL-0: CVE-2015-8615: xen: x86: unintentional

Browse Source 
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
This commit is contained in:
Charles Arnold 2016-01-04 22:25:00 +00:00 committed by Git OBS Bridge
parent 881e6522ea
commit 8292994238
27 changed files with 1363 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
5628fc67-libxl-No-emulated-disk-driver-for-xvdX-disk.patch Normal file
View File

@ -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 <anthony.perard@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
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",

105
5649bcbe-libxl-relax-readonly-check-introduced-by-XSA-142-fix.patch Normal file
View File

@ -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 <jfehlig@suse.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
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");

25
56549f24-x86-vPMU-document-as-unsupported.patch Normal file
View File

@ -0,0 +1,25 @@
# Commit c03480cf5c4e96fb4afb2237ad0a3cac7162564a
# Date 2015-11-24 18:32:20 +0100
# Author Jan Beulich <jbeulich@suse.com>
# Committer Jan Beulich <jbeulich@suse.com>
x86/vPMU: document as unsupported
This is XSA-163.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
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>`

40
5677f350-x86-make-debug-output-consistent-in-hvm_set_callback_via.patch Normal file
View File

@ -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 <malcolm.crossley@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
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)

53
CVE-2015-7549-qemuu-pci-null-pointer-dereference-issue.patch Normal file
View File

@ -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 <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 <marcandre.lureau@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
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,

34
CVE-2015-8345-qemut-eepro100-infinite-loop-fix.patch Normal file
View File

@ -0,0 +1,34 @@
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

34
CVE-2015-8345-qemuu-eepro100-infinite-loop-fix.patch Normal file
View File

@ -0,0 +1,34 @@
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);

25
CVE-2015-8504-qemut-vnc-avoid-floating-point-exception.patch Normal file
View File

@ -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;

25
CVE-2015-8504-qemuu-vnc-avoid-floating-point-exception.patch Normal file
View File

@ -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;

39
CVE-2015-8558-qemuu-usb-infinite-loop-in-ehci_advance_state-results-in-DoS.patch Normal file
View File

@ -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 <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;
}

89
CVE-2015-8568-qemuu-net-vmxnet3-avoid-memory-leakage-in-activate_device.patch Normal file
View File

@ -0,0 +1,89 @@
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);
}

80
xen.changes
View File

@ -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

78
xen.spec
View File

@ -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

52
xsa155-qemut-qdisk-double-access.patch Normal file
View File

@ -0,0 +1,52 @@
References: bsc#957988
From 27942b0cb2327e93deb12326bbe7b36c81f9fa7b Mon Sep 17 00:00:00 2001
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
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 <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
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];
}

49
xsa155-qemut-xenfb.patch Normal file
View File

@ -0,0 +1,49 @@
References: bsc#957988
From 0ffd4547665d2fec648ab2c9ff856c5d9db9b07c Mon Sep 17 00:00:00 2001
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
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 <stefano.stabellini@eu.citrix.com>
---
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;

43
xsa155-qemuu-qdisk-double-access.patch Normal file
View File

@ -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 <stefano.stabellini@eu.citrix.com>
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];
}

43
xsa155-qemuu-xenfb.patch Normal file
View File

@ -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 <stefano.stabellini@eu.citrix.com>
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;

55
xsa155-xen-0001-xen-Add-RING_COPY_REQUEST.patch Normal file
View File

@ -0,0 +1,55 @@
References: bsc#957988
From 12b11658a9d6a654a1e7acbf2f2d56ce9a396c86 Mon Sep 17 00:00:00 2001
From: David Vrabel <david.vrabel@citrix.com>
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 <david.vrabel@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
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))

74
xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch Normal file
View File

@ -0,0 +1,74 @@
References: bsc#957988
From 851ffb4eea917e2708c912291dea4d133026c0ac Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
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 <konrad.wilk@oracle.com>
---
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;

38
xsa155-xen-0003-libvchan-Read-prod-cons-only-once.patch Normal file
View File

@ -0,0 +1,38 @@
From c1fce65e2b720684ea6ba76ae59921542bd154bb Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
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 <konrad.wilk@oracle.com>
---
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. */

48
xsa159.patch Normal file
View File

@ -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 <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
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);

63
xsa160.patch Normal file
View File

@ -0,0 +1,63 @@
From adcbd15b1aec8367f790774c998db199c9b577bf Mon Sep 17 00:00:00 2001
From: Ian Jackson <ian.jackson@eu.citrix.com>
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 <ian.campbell@citrix.com>
---
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);

43
xsa162-qemut.patch Normal file
View File

@ -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;

37
xsa162-qemuu.patch Normal file
View File

@ -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;
}

37
xsa164.patch Normal file
View File

@ -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 <jbeulich@suse.com>
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;

89
xsa165.patch Normal file
View File

@ -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 <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
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;
}

48
xsa166.patch Normal file
View File

@ -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 <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
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 */