SHA256
1
0
forked from pool/xen
xen/ioemu-vnc-resize.patch
Charles Arnold 39134eb9d2 - bsc#962758 - VUL-0: CVE-2013-4539: xen: tsc210x: buffer overrun
on invalid state load
  CVE-2013-4539-qemut-tsc210x-fix-buffer-overrun-on-invalid-state-load.patch

- bsc#962632 - VUL-0: CVE-2015-1779: xen: vnc: insufficient
  resource limiting in VNC websockets decoder
  CVE-2015-1779-qemuu-limit-size-of-HTTP-headers-from-websockets-clients.patch
  CVE-2015-1779-qemuu-incrementally-decode-websocket-frames.patch
- bsc#962642 - VUL-0: CVE-2013-4537: xen: ssi-sd: buffer overrun on
  invalid state load
  CVE-2013-4537-qemut-ssi-sd-fix-buffer-overrun-on-invalid-state-load.patch
- bsc#962627 - VUL-0: CVE-2014-7815: xen: vnc: insufficient
  bits_per_pixel from the client sanitization
  CVE-2014-7815-qemut-vnc-sanitize-bits_per_pixel-from-the-client.patch

- bsc#962335 - VUL-0: CVE-2013-4538: xen: ssd0323: fix buffer
  overun on invalid state
  CVE-2013-4538-qemut-ssd0323-fix-buffer-overun-on-invalid-state.patch
- bsc#962360 - VUL-0: CVE-2015-7512: xen: net: pcnet: buffer
  overflow in non-loopback mode
  CVE-2015-7512-qemuu-net-pcnet-buffer-overflow-in-non-loopback-mode.patch
  CVE-2015-7512-qemut-net-pcnet-buffer-overflow-in-non-loopback-mode.patch

- bsc#961692 - VUL-0: CVE-2016-1714: xen: nvram: OOB r/w access in
  processing firmware configurations
  CVE-2016-1714-qemuu-fw_cfg-add-check-to-validate-current-entry-value.patch
  CVE-2016-1714-qemut-fw_cfg-add-check-to-validate-current-entry-value.patch

- bsc#961358 - VUL-0: CVE-2015-8613: xen: qemu: scsi: stack based
  buffer overflow in megasas_ctrl_get_info

OBS-URL: https://build.opensuse.org/package/show/Virtualization/xen?expand=0&rev=395
2016-01-20 16:26:32 +00:00

31 lines
1.1 KiB
Diff

Index: xen-4.6.0-testing/tools/qemu-xen-traditional-dir-remote/vnc.c
===================================================================
--- xen-4.6.0-testing.orig/tools/qemu-xen-traditional-dir-remote/vnc.c
+++ xen-4.6.0-testing/tools/qemu-xen-traditional-dir-remote/vnc.c
@@ -1761,6 +1761,25 @@ static int protocol_client_msg(VncState
}
set_encodings(vs, (int32_t *)(data + 4), limit);
+
+ /*
+ * The initialization of a VNC connection can race with xenfb changing
+ * the resolution. This happens when the VNC connection is already
+ * established, but the client has not yet advertised has_resize, so it
+ * won't get notified of the switch.
+ *
+ * Therefore we resend the resolution as soon as the client has sent its
+ * encodings.
+ */
+ if (vs->has_resize) {
+ /* Resize the VNC window */
+ vnc_write_u8(vs, 0); /* msg id */
+ vnc_write_u8(vs, 0);
+ vnc_write_u16(vs, 1); /* number of rects */
+ vnc_framebuffer_update(vs, 0, 0, vs->serverds.width, vs->serverds.height, -223);
+
+ vnc_flush(vs);
+ }
break;
case 3:
if (len == 1)