flight 80731 qemu-upstream-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/80731/
Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 77858 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 77858 test-amd64-amd64-qemuu-nested-amd 9 debian-hvm-install fail REGR. vs. 77858 test-amd64-i386-qemuu-rhel6hvm-intel 9 redhat-install fail REGR. vs. 77858 test-armhf-armhf-libvirt-raw 6 xen-boot fail REGR. vs. 77858 test-amd64-i386-qemuu-rhel6hvm-amd 9 redhat-install fail REGR. vs. 77858 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 77858 test-amd64-amd64-xl-qemuu-winxpsp3 9 windows-install fail REGR. vs. 77858 test-amd64-i386-xl-qemuu-winxpsp3 9 windows-install fail REGR. vs. 77858 test-amd64-amd64-xl-qemuu-win7-amd64 9 windows-install fail REGR. vs. 77858 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail REGR. vs. 77858 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 11 guest-start fail REGR. vs. 77858 test-amd64-amd64-qemuu-nested-intel 9 debian-hvm-install fail like 77752 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail like 77752 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail like 77752 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt 14 guest-saverestore fail never pass test-armhf-armhf-libvirt 12 migrate-support-check fail never pass test-amd64-i386-libvirt 12 migrate-support-check fail never pass test-amd64-amd64-libvirt 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-qcow2 10 guest-start fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 10 guest-start fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail never pass test-armhf-armhf-xl 12 migrate-support-check fail never pass test-armhf-armhf-xl 13 saverestore-support-check fail never pass version targeted for testing: qemuu 9497b3fec7842f42617a6aa479b5e4f4bcdbeb1d baseline version: qemuu 32bba3499008c847e08858f310d65806e0bade36 Last test of basis 77858 2016-01-11 19:23:09 Z 29 days Testing same since 80731 2016-02-05 15:18:36 Z 4 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Gerd Hoffmann <[email protected]> Jason Wang <[email protected]> John Snow <[email protected]> Laszlo Ersek <[email protected]> P J P <[email protected]> Paolo Bonzini <[email protected]> Peter Maydell <[email protected]> Prasad J Pandit <[email protected]> Roger Pau Monne <[email protected]> Roger Pau Monné <[email protected]> Stefano Stabellini <[email protected]> jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel fail test-amd64-amd64-xl-pvh-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt fail test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 fail test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xl-qemuu-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 9497b3fec7842f42617a6aa479b5e4f4bcdbeb1d Author: Prasad J Pandit <[email protected]> Date: Fri Nov 20 11:50:31 2015 +0530 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. Reported by: Qinghao Tang <[email protected]> Cc: [email protected] Reviewed-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Prasad J Pandit <[email protected]> Signed-off-by: Jason Wang <[email protected]> commit 3f19ed9b07fb2e14cb99616a15c209fd2e8170eb Author: Jason Wang <[email protected]> Date: Mon Nov 30 15:00:06 2015 +0800 pcnet: fix rx buffer overflow(CVE-2015-7512) Backends could provide a packet whose length is greater than buffer size. Check for this and truncate the packet to avoid rx buffer overflow in this case. Cc: Prasad J Pandit <[email protected]> Cc: [email protected] Reviewed-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Jason Wang <[email protected]> commit e27727dc5c9bd67e78ee4c36465ac3b23f3997d4 Author: Gerd Hoffmann <[email protected]> Date: Mon Dec 14 09:21:23 2015 +0100 ehci: make idt processing more robust 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. This is CVE-2015-8558. Cc: [email protected] Reported-by: Qinghao Tang <[email protected]> Tested-by: P J P <[email protected]> Signed-off-by: Gerd Hoffmann <[email protected]> commit 9a5a7327425fb18a210728f397df4fbc577019c7 Author: Prasad J Pandit <[email protected]> Date: Mon Jan 25 19:59:50 2016 +0530 exec: fix a glitch in checking dma r/w access While checking r/w access in 'memory_access_is_direct' routine a glitch in the expression leads to segmentation fault while performing dma read operation. Reported-by: Donghai Zdh <[email protected]> Signed-off-by: Prasad J Pandit <[email protected]> commit 2947784b8480d4c7ef0a42980bf75adc3138a248 Author: Prasad J Pandit <[email protected]> Date: Wed Jan 20 01:26:46 2016 +0530 usb: check page select value while processing iTD While processing isochronous transfer descriptors(iTD), the page select(PG) field value could lead to an OOB read access. Add check to avoid it. Reported-by: Qinghao Tang <[email protected]> Signed-off-by: Prasad J Pandit <[email protected]> Message-id: [email protected] Signed-off-by: Gerd Hoffmann <[email protected]> commit a136dd80ade511360d1cec99554c5e160cbd64af Author: Prasad J Pandit <[email protected]> Date: Fri Jan 15 12:30:40 2016 +0530 net: cadence_gem: check packet size in gem_recieve While receiving packets in 'gem_receive' routine, if Frame Check Sequence(FCS) is enabled, it copies the packet into a local buffer without checking its size. Add check to validate packet length against the buffer size to avoid buffer overflow. Reported-by: Ling Liu <[email protected]> Signed-off-by: Prasad J Pandit <[email protected]> Signed-off-by: Jason Wang <[email protected]> commit 1c0abfea58ee70b54d319cb1407824340f5deed7 Author: Prasad J Pandit <[email protected]> Date: Fri Feb 5 13:58:20 2016 +0000 ide: ahci: reset ncq object to unused on error When processing NCQ commands, AHCI device emulation prepares a NCQ transfer object; To which an aio control block(aiocb) object is assigned in 'execute_ncq_command'. In case, when the NCQ command is invalid, the 'aiocb' object is not assigned, and NCQ transfer object is left as 'used'. This leads to a use after free kind of error in 'bdrv_aio_cancel_async' via 'ahci_reset_port'. Reset NCQ transfer object to 'unused' to avoid it. [Maintainer edit: s/ACHI/AHCI/ in the commit message. --js] Reported-by: Qinghao Tang <[email protected]> Signed-off-by: Prasad J Pandit <[email protected]> Reviewed-by: John Snow <[email protected]> Message-id: [email protected] Signed-off-by: John Snow <[email protected]> Signed-off-by: Stefano Stabellini <[email protected]> commit ae393c6d2c23dc1a797cdbad7f64d0810eda75d6 Author: Prasad J Pandit <[email protected]> Date: Thu Dec 31 17:05:27 2015 +0530 net: ne2000: fix bounds check in ioport operations While doing ioport r/w operations, ne2000 device emulation suffers from OOB r/w errors. Update respective array bounds check to avoid OOB access. Reported-by: Ling Liu <[email protected]> Cc: [email protected] Signed-off-by: Prasad J Pandit <[email protected]> Signed-off-by: Jason Wang <[email protected]> commit b402c283d4edc25d8eafae95329cea38a5b305f9 Author: P J P <[email protected]> Date: Mon Dec 21 15:13:13 2015 +0530 scsi: initialise info object with appropriate size While processing controller 'CTRL_GET_INFO' command, the routine 'megasas_ctrl_get_info' overflows the '&info' object size. Use its appropriate size to null initialise it. Reported-by: Qinghao Tang <[email protected]> Signed-off-by: Prasad J Pandit <[email protected]> Message-Id: <alpine.LFD.2.20.1512211501420.22471@wniryva> Cc: [email protected] Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: P J P <[email protected]> commit b993d1eba4c5ef89ba5bdbcaac63f4d668bdc8c6 Author: P J P <[email protected]> Date: Tue Dec 15 12:27:54 2015 +0530 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 <[email protected]> Reviewed-by: Dmitry Fleytman <[email protected]> Signed-off-by: Prasad J Pandit <[email protected]> Cc: [email protected] Signed-off-by: Jason Wang <[email protected]> commit ca4b8af6798b1e21c3ef4dfa8df7fbb133f55396 Author: Prasad J Pandit <[email protected]> Date: Thu Dec 3 18:54:17 2015 +0530 ui: vnc: avoid floating point exception While sending 'SetPixelFormat' messages to a VNC server, the client could set the 'red-max', 'green-max' and 'blue-max' values to be zero. This leads to a floating point exception in write_png_palette while doing frame buffer updates. Reported-by: Lian Yihan <[email protected]> Signed-off-by: Prasad J Pandit <[email protected]> Reviewed-by: Gerd Hoffmann <[email protected]> Signed-off-by: Peter Maydell <[email protected]> commit 78668ee0d72990e083177465f15584a893ebf884 Author: Laszlo Ersek <[email protected]> Date: Tue Jan 19 14:17:20 2016 +0100 e1000: eliminate infinite loops on out-of-bounds transfer start The start_xmit() and e1000_receive_iov() functions implement DMA transfers iterating over a set of descriptors that the guest's e1000 driver prepares: - the TDLEN and RDLEN registers store the total size of the descriptor area, - while the TDH and RDH registers store the offset (in whole tx / rx descriptors) into the area where the transfer is supposed to start. Each time a descriptor is processed, the TDH and RDH register is bumped (as appropriate for the transfer direction). QEMU already contains logic to deal with bogus transfers submitted by the guest: - Normally, the transmit case wants to increase TDH from its initial value to TDT. (TDT is allowed to be numerically smaller than the initial TDH value; wrapping at or above TDLEN bytes to zero is normal.) The failsafe that QEMU currently has here is a check against reaching the original TDH value again -- a complete wraparound, which should never happen. - In the receive case RDH is increased from its initial value until "total_size" bytes have been received; preferably in a single step, or in "s->rxbuf_size" byte steps, if the latter is smaller. However, null RX descriptors are skipped without receiving data, while RDH is incremented just the same. QEMU tries to prevent an infinite loop (processing only null RX descriptors) by detecting whether RDH assumes its original value during the loop. (Again, wrapping from RDLEN to 0 is normal.) What both directions miss is that the guest could program TDLEN and RDLEN so low, and the initial TDH and RDH so high, that these registers will immediately be truncated to zero, and then never reassume their initial values in the loop -- a full wraparound will never occur. The condition that expresses this is: xdh_start >= s->mac_reg[XDLEN] / sizeof(desc) i.e., TDH or RDH start out after the last whole rx or tx descriptor that fits into the TDLEN or RDLEN sized area. This condition could be checked before we enter the loops, but pci_dma_read() / pci_dma_write() knows how to fill in buffers safely for bogus DMA addresses, so we just extend the existing failsafes with the above condition. This is CVE-2016-1981. upstream-commit-id: dd793a74882477ca38d49e191110c17dfee51dcc Cc: "Michael S. Tsirkin" <[email protected]> Cc: Petr Matousek <[email protected]> Cc: Stefano Stabellini <[email protected]> Cc: Prasad Pandit <[email protected]> Cc: Michael Roth <[email protected]> Cc: Jason Wang <[email protected]> Cc: [email protected] RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1296044 Signed-off-by: Laszlo Ersek <[email protected]> Reviewed-by: Jason Wang <[email protected]> Signed-off-by: Jason Wang <[email protected]> Signed-off-by: Stefano Stabellini <[email protected]> commit ebaa23ffb84d8bf8a114e67d49041d9afdee3a56 Author: Roger Pau Monne <[email protected]> Date: Fri Nov 13 17:38:06 2015 +0000 xen: fix usage of xc_domain_create in domain builder Due to the addition of HVMlite and the requirement to always provide a valid xc_domain_configuration_t, xc_domain_create now always takes an arch domain config, which can be NULL in order to mimic previous behaviour. Add a small stub called xen_domain_create that encapsulates the correct call to xc_domain_create depending on the libxc version detected. Signed-off-by: Roger Pau Monné <[email protected]> Acked-by: Stefano Stabellini <[email protected]> Signed-off-by: Stefano Stabellini <[email protected]> commit f662c5972a54f2f4b218d9ace5c3b10ae9a15b7e Author: Prasad J Pandit <[email protected]> Date: Wed Jan 6 11:46:25 2016 +0530 fw_cfg: add check to validate current entry value When processing firmware configurations, an OOB r/w access occurs if 's->cur_entry' is set to be invalid(FW_CFG_INVALID=0xffff). Add a check to validate 's->cur_entry' to avoid such access. Reported-by: Donghai Zdh <[email protected]> Signed-off-by: Prasad J Pandit <[email protected]> Signed-off-by: Stefano Stabellini <[email protected]>
_______________________________________________ Xen-devel mailing list [email protected] http://lists.xen.org/xen-devel
