* [qemu-upstream-4.11-testing test] 137100: regressions - FAIL
@ 2019-06-01 8:43 ` osstest service owner
0 siblings, 0 replies; 6+ messages in thread
From: osstest service owner @ 2019-06-01 8:43 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 137100 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137100/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops <job status> broken in 134504
build-arm64-xsm <job status> broken in 134504
build-arm64 <job status> broken in 134504
build-arm64-xsm 4 host-install(4) broken in 134504 REGR. vs. 125575
build-arm64 4 host-install(4) broken in 134504 REGR. vs. 125575
build-arm64-pvops 4 host-install(4) broken in 134504 REGR. vs. 125575
test-arm64-arm64-xl 7 xen-boot fail REGR. vs. 125575
test-arm64-arm64-libvirt-xsm 7 xen-boot fail REGR. vs. 125575
test-arm64-arm64-xl-credit2 7 xen-boot fail REGR. vs. 125575
test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 125575
build-i386-libvirt 6 libvirt-build fail in 135205 REGR. vs. 125575
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 18 guest-start/debianhvm.repeat fail in 134504 pass in 135205
test-amd64-amd64-xl-multivcpu 12 guest-start fail in 134504 pass in 137100
test-amd64-amd64-xl-pvshim 12 guest-start fail in 134504 pass in 137100
test-amd64-amd64-xl-rtds 12 guest-start fail in 134504 pass in 137100
test-amd64-amd64-libvirt-xsm 12 guest-start fail in 134504 pass in 137100
test-amd64-i386-libvirt 12 guest-start fail in 134504 pass in 137100
test-armhf-armhf-xl-arndale 12 guest-start fail in 134504 pass in 137100
test-amd64-i386-xl-shadow 20 guest-start/debian.repeat fail in 134504 pass in 137100
test-amd64-i386-xl 20 guest-start/debian.repeat fail in 134504 pass in 137100
test-amd64-i386-libvirt-xsm 20 guest-destroy fail in 134504 pass in 137100
test-amd64-i386-xl-xsm 20 guest-start/debian.repeat fail in 134504 pass in 137100
test-armhf-armhf-libvirt 12 guest-start fail in 134504 pass in 137100
test-armhf-armhf-xl-rtds 12 guest-start fail in 134504 pass in 137100
test-amd64-i386-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail in 134504 pass in 137100
test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 134504 pass in 137100
test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeat fail in 134504 pass in 137100
test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail in 134504 pass in 137100
test-amd64-amd64-xl-qcow2 16 guest-saverestore.2 fail in 135205 pass in 137100
test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail pass in 134504
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked in 134504 n/a
build-arm64-libvirt 1 build-check(1) blocked in 134504 n/a
test-arm64-arm64-xl-xsm 1 build-check(1) blocked in 134504 n/a
test-arm64-arm64-xl-credit2 1 build-check(1) blocked in 134504 n/a
test-arm64-arm64-xl-credit1 1 build-check(1) blocked in 134504 n/a
test-arm64-arm64-xl 1 build-check(1) blocked in 134504 n/a
test-amd64-i386-libvirt-pair 1 build-check(1) blocked in 135205 n/a
test-amd64-i386-libvirt 1 build-check(1) blocked in 135205 n/a
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 135205 n/a
test-amd64-i386-libvirt-xsm 1 build-check(1) blocked in 135205 n/a
test-armhf-armhf-xl-credit1 16 guest-start/debian.repeat fail in 134504 baseline untested
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-xl-pvshim 12 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit1 7 xen-boot fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt 13 migrate-support-check fail never pass
test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
version targeted for testing:
qemuu 2871355a6957f1b3c16f858e3143e0fff0737b6a
baseline version:
qemuu 20c76f9a5fbf16d58c6add2ace2ff0fabd785926
Last test of basis 125575 2018-07-25 18:53:54 Z 310 days
Testing same since 134270 2019-04-01 16:10:50 Z 60 days 27 attempts
------------------------------------------------------------
People who touched revisions under test:
Anthony PERARD <anthony.perard@citrix.com>
Gerd Hoffmann <kraxel@redhat.com>
Greg Kurz <groug@kaod.org>
Jason Wang <jasowang@redhat.com>
Kevin Wolf <kwolf@redhat.com>
Li Qiang <liq3ea@gmail.com>
Michael McConville <mmcco@mykolab.com>
Michael Tokarev <mjt@tls.msk.ru>
Niels de Vos <ndevos@redhat.com>
Paolo Bonzini <pbonzini@redhat.com>
Peter Maydell <peter.maydell@linaro.org>
Philippe Mathieu-Daudé <philmd@redhat.com>
Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Roger Pau Monne <roger.pau@citrix.com>
Roger Pau Monné <roger.pau@citrix.com>
jobs:
build-amd64-xsm pass
build-arm64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-arm64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-arm64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-arm64-arm64-xl fail
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-arm64-arm64-libvirt-xsm fail
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-arm64-arm64-xl-xsm fail
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvhv2-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit1 pass
test-arm64-arm64-xl-credit1 fail
test-armhf-armhf-xl-credit1 pass
test-amd64-amd64-xl-credit2 pass
test-arm64-arm64-xl-credit2 fail
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail
test-amd64-i386-freebsd10-i386 pass
test-amd64-amd64-xl-qemuu-win10-i386 fail
test-amd64-i386-xl-qemuu-win10-i386 fail
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvhv2-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
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-xl-pvshim pass
test-amd64-i386-xl-pvshim fail
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2 fail
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-amd64-xl-shadow pass
test-amd64-i386-xl-shadow pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
------------------------------------------------------------
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
broken-job build-arm64-pvops broken
broken-job build-arm64-xsm broken
broken-job build-arm64 broken
Not pushing.
------------------------------------------------------------
commit 2871355a6957f1b3c16f858e3143e0fff0737b6a
Author: Kevin Wolf <kwolf@redhat.com>
Date: Thu Oct 11 17:30:39 2018 +0200
gtk: Don't vte_terminal_set_encoding() on new VTE versions
The function vte_terminal_set_encoding() is deprecated since VTE 0.54,
so stop calling it from that version on. This fixes a build error
because of our use of warning flags [-Werror=deprecated-declarations].
Fixes: https://bugs.launchpad.net/bugs/1794939
Reported-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-id: 20181011153039.2324-1-kwolf@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 6415994ffcc6d22b3f5add67f63fe77e4b9711f4)
commit 94a715b6cba7225e5db59901e5d0a5252ead9755
Author: Niels de Vos <ndevos@redhat.com>
Date: Tue Mar 5 16:46:34 2019 +0100
gluster: the glfs_io_cbk callback function pointer adds pre/post stat args
The glfs_*_async() functions do a callback once finished. This callback
has changed its arguments, pre- and post-stat structures have been
added. This makes it possible to improve caching, which is useful for
Samba and NFS-Ganesha, but not so much for QEMU. Gluster 6 is the first
release that includes these new arguments.
With an additional detection in ./configure, the new arguments can
conditionally get included in the glfs_io_cbk handler.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 0e3b891fefacc0e49f3c8ffa3a753b69eb7214d2)
commit 13bac7abf60e25101ef6059f0da7a168942eccd9
Author: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Date: Tue Mar 5 16:46:33 2019 +0100
gluster: Handle changed glfs_ftruncate signature
New versions of Glusters libgfapi.so have an updated glfs_ftruncate()
function that returns additional 'struct stat' structures to enable
advanced caching of attributes. This is useful for file servers, not so
much for QEMU. Nevertheless, the API has changed and needs to be
adopted.
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit e014dbe74e0484188164c61ff6843f8a04a8cb9d)
commit 9864a12f4a13f19a7440cb32bd3242506d6b2738
Author: Jason Wang <jasowang@redhat.com>
Date: Tue Dec 4 11:53:43 2018 +0800
net: drop too large packet early
We try to detect and drop too large packet (>INT_MAX) in 1592a9947036
("net: ignore packet size greater than INT_MAX") during packet
delivering. Unfortunately, this is not sufficient as we may hit
another integer overflow when trying to queue such large packet in
qemu_net_queue_append_iov():
- size of the allocation may overflow on 32bit
- packet->size is integer which may overflow even on 64bit
Fixing this by moving the check to qemu_sendv_packet_async() which is
the entrance of all networking codes and reduce the limit to
NET_BUFSIZE to be more conservative. This works since:
- For the callers that call qemu_sendv_packet_async() directly, they
only care about if zero is returned to determine whether to prevent
the source from producing more packets. A callback will be triggered
if peer can accept more then source could be enabled. This is
usually used by high speed networking implementation like virtio-net
or netmap.
- For the callers that call qemu_sendv_packet() that calls
qemu_sendv_packet_async() indirectly, they often ignore the return
value. In this case qemu will just the drop packets if peer can't
receive.
Qemu will copy the packet if it was queued. So it was safe for both
kinds of the callers to assume the packet was sent.
Since we move the check from qemu_deliver_packet_iov() to
qemu_sendv_packet_async(), it would be safer to make
qemu_deliver_packet_iov() static to prevent any external user in the
future.
This is a revised patch of CVE-2018-17963.
Cc: qemu-stable@nongnu.org
Cc: Li Qiang <liq3ea@163.com>
Fixes: 1592a9947036 ("net: ignore packet size greater than INT_MAX")
Reported-by: Li Qiang <liq3ea@gmail.com>
Reviewed-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-id: 20181204035347.6148-2-jasowang@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 25c01bd19d0e4b66f357618aeefda1ef7a41e21a)
commit b697c0aecbf9bc8bdb4f1bf0ea92e6a8fb258094
Author: Jason Wang <jasowang@redhat.com>
Date: Wed May 30 13:16:36 2018 +0800
net: ignore packet size greater than INT_MAX
There should not be a reason for passing a packet size greater than
INT_MAX. It's usually a hint of bug somewhere, so ignore packet size
greater than INT_MAX in qemu_deliver_packet_iov()
CC: qemu-stable@nongnu.org
Reported-by: Daniel Shapira <daniel@twistlock.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 1592a9947036d60dde5404204a5d45975133caf5)
commit f517c1b6079a514c0798eacb3f7c77b9dd8ebbf1
Author: Greg Kurz <groug@kaod.org>
Date: Fri Nov 23 13:28:03 2018 +0100
9p: fix QEMU crash when renaming files
When using the 9P2000.u version of the protocol, the following shell
command line in the guest can cause QEMU to crash:
while true; do rm -rf aa; mkdir -p a/b & touch a/b/c & mv a aa; done
With 9P2000.u, file renaming is handled by the WSTAT command. The
v9fs_wstat() function calls v9fs_complete_rename(), which calls
v9fs_fix_path() for every fid whose path is affected by the change.
The involved calls to v9fs_path_copy() may race with any other access
to the fid path performed by some worker thread, causing a crash like
shown below:
Thread 12 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
0x0000555555a25da2 in local_open_nofollow (fs_ctx=0x555557d958b8, path=0x0,
flags=65536, mode=0) at hw/9pfs/9p-local.c:59
59 while (*path && fd != -1) {
(gdb) bt
#0 0x0000555555a25da2 in local_open_nofollow (fs_ctx=0x555557d958b8,
path=0x0, flags=65536, mode=0) at hw/9pfs/9p-local.c:59
#1 0x0000555555a25e0c in local_opendir_nofollow (fs_ctx=0x555557d958b8,
path=0x0) at hw/9pfs/9p-local.c:92
#2 0x0000555555a261b8 in local_lstat (fs_ctx=0x555557d958b8,
fs_path=0x555556b56858, stbuf=0x7fff84830ef0) at hw/9pfs/9p-local.c:185
#3 0x0000555555a2b367 in v9fs_co_lstat (pdu=0x555557d97498,
path=0x555556b56858, stbuf=0x7fff84830ef0) at hw/9pfs/cofile.c:53
#4 0x0000555555a1e9e2 in v9fs_stat (opaque=0x555557d97498)
at hw/9pfs/9p.c:1083
#5 0x0000555555e060a2 in coroutine_trampoline (i0=-669165424, i1=32767)
at util/coroutine-ucontext.c:116
#6 0x00007fffef4f5600 in __start_context () at /lib64/libc.so.6
#7 0x0000000000000000 in ()
(gdb)
The fix is to take the path write lock when calling v9fs_complete_rename(),
like in v9fs_rename().
Impact: DoS triggered by unprivileged guest users.
Fixes: CVE-2018-19489
Cc: P J P <ppandit@redhat.com>
Reported-by: zhibin hu <noirfate@gmail.com>
Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Greg Kurz <groug@kaod.org>
(cherry picked from commit 1d20398694a3b67a388d955b7a945ba4aa90a8a8)
commit 9af9c1c20e313f597168e0522f5fc8d78123b0c8
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Tue Nov 20 19:41:48 2018 +0100
nvme: fix out-of-bounds access to the CMB
Because the CMB BAR has a min_access_size of 2, if you read the last
byte it will try to memcpy *2* bytes from n->cmbuf, causing an off-by-one
error. This is CVE-2018-16847.
Another way to fix this might be to register the CMB as a RAM memory
region, which would also be more efficient. However, that might be a
change for big-endian machines; I didn't think this through and I don't
know how real hardware works. Add a basic testcase for the CMB in case
somebody does this change later on.
Cc: Keith Busch <keith.busch@intel.com>
Cc: qemu-block@nongnu.org
Reported-by: Li Qiang <liq3ea@gmail.com>
Reviewed-by: Li Qiang <liq3ea@gmail.com>
Tested-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 87ad860c622cc8f8916b5232bd8728c08f938fce)
commit c50c704a6a09554925b926c0313280be4a3d7100
Author: Greg Kurz <groug@kaod.org>
Date: Tue Nov 20 13:00:35 2018 +0100
9p: take write lock on fid path updates (CVE-2018-19364)
Recent commit 5b76ef50f62079a fixed a race where v9fs_co_open2() could
possibly overwrite a fid path with v9fs_path_copy() while it is being
accessed by some other thread, ie, use-after-free that can be detected
by ASAN with a custom 9p client.
It turns out that the same can happen at several locations where
v9fs_path_copy() is used to set the fid path. The fix is again to
take the write lock.
Fixes CVE-2018-19364.
Cc: P J P <ppandit@redhat.com>
Reported-by: zhibin hu <noirfate@gmail.com>
Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Greg Kurz <groug@kaod.org>
(cherry picked from commit 5b3c77aa581ebb215125c84b0742119483571e55)
commit 03c28544a1b67fd48ef1fa72231818efa8563874
Author: Roger Pau Monne <roger.pau@citrix.com>
Date: Mon Mar 18 18:37:31 2019 +0100
xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored
Or if it's not possible to honor the hinted address an error is returned
instead. This makes it easier to spot the actual failure, instead of
failing later on when the caller of xen_remap_bucket realizes the
mapping has not been created at the requested address.
Also note that at least on FreeBSD using MAP_FIXED will cause mmap to
try harder to honor the passed address.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Igor Druzhinin <igor.druzhinin@cirtix.com>
Message-Id: <20190318173731.14494-1-roger.pau@citrix.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
(cherry picked from commit 4158e93f4aced247c8db94a0275fc027da7dc97e)
commit a35ed1444329599f2975512c82be795f8af284d5
Author: Michael McConville <mmcco@mykolab.com>
Date: Fri Dec 1 11:31:57 2017 -0700
mmap(2) returns MAP_FAILED, not NULL, on failure
Signed-off-by: Michael McConville <mmcco@mykolab.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit ab1ce9bd4897b9909836e2d50bca86f2f3f2dddc)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Xen-devel] [qemu-upstream-4.11-testing test] 137100: regressions - FAIL
@ 2019-06-01 8:43 ` osstest service owner
0 siblings, 0 replies; 6+ messages in thread
From: osstest service owner @ 2019-06-01 8:43 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 137100 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137100/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops <job status> broken in 134504
build-arm64-xsm <job status> broken in 134504
build-arm64 <job status> broken in 134504
build-arm64-xsm 4 host-install(4) broken in 134504 REGR. vs. 125575
build-arm64 4 host-install(4) broken in 134504 REGR. vs. 125575
build-arm64-pvops 4 host-install(4) broken in 134504 REGR. vs. 125575
test-arm64-arm64-xl 7 xen-boot fail REGR. vs. 125575
test-arm64-arm64-libvirt-xsm 7 xen-boot fail REGR. vs. 125575
test-arm64-arm64-xl-credit2 7 xen-boot fail REGR. vs. 125575
test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 125575
build-i386-libvirt 6 libvirt-build fail in 135205 REGR. vs. 125575
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 18 guest-start/debianhvm.repeat fail in 134504 pass in 135205
test-amd64-amd64-xl-multivcpu 12 guest-start fail in 134504 pass in 137100
test-amd64-amd64-xl-pvshim 12 guest-start fail in 134504 pass in 137100
test-amd64-amd64-xl-rtds 12 guest-start fail in 134504 pass in 137100
test-amd64-amd64-libvirt-xsm 12 guest-start fail in 134504 pass in 137100
test-amd64-i386-libvirt 12 guest-start fail in 134504 pass in 137100
test-armhf-armhf-xl-arndale 12 guest-start fail in 134504 pass in 137100
test-amd64-i386-xl-shadow 20 guest-start/debian.repeat fail in 134504 pass in 137100
test-amd64-i386-xl 20 guest-start/debian.repeat fail in 134504 pass in 137100
test-amd64-i386-libvirt-xsm 20 guest-destroy fail in 134504 pass in 137100
test-amd64-i386-xl-xsm 20 guest-start/debian.repeat fail in 134504 pass in 137100
test-armhf-armhf-libvirt 12 guest-start fail in 134504 pass in 137100
test-armhf-armhf-xl-rtds 12 guest-start fail in 134504 pass in 137100
test-amd64-i386-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail in 134504 pass in 137100
test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 134504 pass in 137100
test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeat fail in 134504 pass in 137100
test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail in 134504 pass in 137100
test-amd64-amd64-xl-qcow2 16 guest-saverestore.2 fail in 135205 pass in 137100
test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail pass in 134504
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked in 134504 n/a
build-arm64-libvirt 1 build-check(1) blocked in 134504 n/a
test-arm64-arm64-xl-xsm 1 build-check(1) blocked in 134504 n/a
test-arm64-arm64-xl-credit2 1 build-check(1) blocked in 134504 n/a
test-arm64-arm64-xl-credit1 1 build-check(1) blocked in 134504 n/a
test-arm64-arm64-xl 1 build-check(1) blocked in 134504 n/a
test-amd64-i386-libvirt-pair 1 build-check(1) blocked in 135205 n/a
test-amd64-i386-libvirt 1 build-check(1) blocked in 135205 n/a
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 135205 n/a
test-amd64-i386-libvirt-xsm 1 build-check(1) blocked in 135205 n/a
test-armhf-armhf-xl-credit1 16 guest-start/debian.repeat fail in 134504 baseline untested
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-xl-pvshim 12 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit1 7 xen-boot fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt 13 migrate-support-check fail never pass
test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
version targeted for testing:
qemuu 2871355a6957f1b3c16f858e3143e0fff0737b6a
baseline version:
qemuu 20c76f9a5fbf16d58c6add2ace2ff0fabd785926
Last test of basis 125575 2018-07-25 18:53:54 Z 310 days
Testing same since 134270 2019-04-01 16:10:50 Z 60 days 27 attempts
------------------------------------------------------------
People who touched revisions under test:
Anthony PERARD <anthony.perard@citrix.com>
Gerd Hoffmann <kraxel@redhat.com>
Greg Kurz <groug@kaod.org>
Jason Wang <jasowang@redhat.com>
Kevin Wolf <kwolf@redhat.com>
Li Qiang <liq3ea@gmail.com>
Michael McConville <mmcco@mykolab.com>
Michael Tokarev <mjt@tls.msk.ru>
Niels de Vos <ndevos@redhat.com>
Paolo Bonzini <pbonzini@redhat.com>
Peter Maydell <peter.maydell@linaro.org>
Philippe Mathieu-Daudé <philmd@redhat.com>
Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Roger Pau Monne <roger.pau@citrix.com>
Roger Pau Monné <roger.pau@citrix.com>
jobs:
build-amd64-xsm pass
build-arm64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-arm64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-arm64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-arm64-arm64-xl fail
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-arm64-arm64-libvirt-xsm fail
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-arm64-arm64-xl-xsm fail
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvhv2-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit1 pass
test-arm64-arm64-xl-credit1 fail
test-armhf-armhf-xl-credit1 pass
test-amd64-amd64-xl-credit2 pass
test-arm64-arm64-xl-credit2 fail
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail
test-amd64-i386-freebsd10-i386 pass
test-amd64-amd64-xl-qemuu-win10-i386 fail
test-amd64-i386-xl-qemuu-win10-i386 fail
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvhv2-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
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-xl-pvshim pass
test-amd64-i386-xl-pvshim fail
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2 fail
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-amd64-xl-shadow pass
test-amd64-i386-xl-shadow pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
------------------------------------------------------------
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
broken-job build-arm64-pvops broken
broken-job build-arm64-xsm broken
broken-job build-arm64 broken
Not pushing.
------------------------------------------------------------
commit 2871355a6957f1b3c16f858e3143e0fff0737b6a
Author: Kevin Wolf <kwolf@redhat.com>
Date: Thu Oct 11 17:30:39 2018 +0200
gtk: Don't vte_terminal_set_encoding() on new VTE versions
The function vte_terminal_set_encoding() is deprecated since VTE 0.54,
so stop calling it from that version on. This fixes a build error
because of our use of warning flags [-Werror=deprecated-declarations].
Fixes: https://bugs.launchpad.net/bugs/1794939
Reported-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-id: 20181011153039.2324-1-kwolf@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 6415994ffcc6d22b3f5add67f63fe77e4b9711f4)
commit 94a715b6cba7225e5db59901e5d0a5252ead9755
Author: Niels de Vos <ndevos@redhat.com>
Date: Tue Mar 5 16:46:34 2019 +0100
gluster: the glfs_io_cbk callback function pointer adds pre/post stat args
The glfs_*_async() functions do a callback once finished. This callback
has changed its arguments, pre- and post-stat structures have been
added. This makes it possible to improve caching, which is useful for
Samba and NFS-Ganesha, but not so much for QEMU. Gluster 6 is the first
release that includes these new arguments.
With an additional detection in ./configure, the new arguments can
conditionally get included in the glfs_io_cbk handler.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 0e3b891fefacc0e49f3c8ffa3a753b69eb7214d2)
commit 13bac7abf60e25101ef6059f0da7a168942eccd9
Author: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Date: Tue Mar 5 16:46:33 2019 +0100
gluster: Handle changed glfs_ftruncate signature
New versions of Glusters libgfapi.so have an updated glfs_ftruncate()
function that returns additional 'struct stat' structures to enable
advanced caching of attributes. This is useful for file servers, not so
much for QEMU. Nevertheless, the API has changed and needs to be
adopted.
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit e014dbe74e0484188164c61ff6843f8a04a8cb9d)
commit 9864a12f4a13f19a7440cb32bd3242506d6b2738
Author: Jason Wang <jasowang@redhat.com>
Date: Tue Dec 4 11:53:43 2018 +0800
net: drop too large packet early
We try to detect and drop too large packet (>INT_MAX) in 1592a9947036
("net: ignore packet size greater than INT_MAX") during packet
delivering. Unfortunately, this is not sufficient as we may hit
another integer overflow when trying to queue such large packet in
qemu_net_queue_append_iov():
- size of the allocation may overflow on 32bit
- packet->size is integer which may overflow even on 64bit
Fixing this by moving the check to qemu_sendv_packet_async() which is
the entrance of all networking codes and reduce the limit to
NET_BUFSIZE to be more conservative. This works since:
- For the callers that call qemu_sendv_packet_async() directly, they
only care about if zero is returned to determine whether to prevent
the source from producing more packets. A callback will be triggered
if peer can accept more then source could be enabled. This is
usually used by high speed networking implementation like virtio-net
or netmap.
- For the callers that call qemu_sendv_packet() that calls
qemu_sendv_packet_async() indirectly, they often ignore the return
value. In this case qemu will just the drop packets if peer can't
receive.
Qemu will copy the packet if it was queued. So it was safe for both
kinds of the callers to assume the packet was sent.
Since we move the check from qemu_deliver_packet_iov() to
qemu_sendv_packet_async(), it would be safer to make
qemu_deliver_packet_iov() static to prevent any external user in the
future.
This is a revised patch of CVE-2018-17963.
Cc: qemu-stable@nongnu.org
Cc: Li Qiang <liq3ea@163.com>
Fixes: 1592a9947036 ("net: ignore packet size greater than INT_MAX")
Reported-by: Li Qiang <liq3ea@gmail.com>
Reviewed-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-id: 20181204035347.6148-2-jasowang@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 25c01bd19d0e4b66f357618aeefda1ef7a41e21a)
commit b697c0aecbf9bc8bdb4f1bf0ea92e6a8fb258094
Author: Jason Wang <jasowang@redhat.com>
Date: Wed May 30 13:16:36 2018 +0800
net: ignore packet size greater than INT_MAX
There should not be a reason for passing a packet size greater than
INT_MAX. It's usually a hint of bug somewhere, so ignore packet size
greater than INT_MAX in qemu_deliver_packet_iov()
CC: qemu-stable@nongnu.org
Reported-by: Daniel Shapira <daniel@twistlock.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 1592a9947036d60dde5404204a5d45975133caf5)
commit f517c1b6079a514c0798eacb3f7c77b9dd8ebbf1
Author: Greg Kurz <groug@kaod.org>
Date: Fri Nov 23 13:28:03 2018 +0100
9p: fix QEMU crash when renaming files
When using the 9P2000.u version of the protocol, the following shell
command line in the guest can cause QEMU to crash:
while true; do rm -rf aa; mkdir -p a/b & touch a/b/c & mv a aa; done
With 9P2000.u, file renaming is handled by the WSTAT command. The
v9fs_wstat() function calls v9fs_complete_rename(), which calls
v9fs_fix_path() for every fid whose path is affected by the change.
The involved calls to v9fs_path_copy() may race with any other access
to the fid path performed by some worker thread, causing a crash like
shown below:
Thread 12 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
0x0000555555a25da2 in local_open_nofollow (fs_ctx=0x555557d958b8, path=0x0,
flags=65536, mode=0) at hw/9pfs/9p-local.c:59
59 while (*path && fd != -1) {
(gdb) bt
#0 0x0000555555a25da2 in local_open_nofollow (fs_ctx=0x555557d958b8,
path=0x0, flags=65536, mode=0) at hw/9pfs/9p-local.c:59
#1 0x0000555555a25e0c in local_opendir_nofollow (fs_ctx=0x555557d958b8,
path=0x0) at hw/9pfs/9p-local.c:92
#2 0x0000555555a261b8 in local_lstat (fs_ctx=0x555557d958b8,
fs_path=0x555556b56858, stbuf=0x7fff84830ef0) at hw/9pfs/9p-local.c:185
#3 0x0000555555a2b367 in v9fs_co_lstat (pdu=0x555557d97498,
path=0x555556b56858, stbuf=0x7fff84830ef0) at hw/9pfs/cofile.c:53
#4 0x0000555555a1e9e2 in v9fs_stat (opaque=0x555557d97498)
at hw/9pfs/9p.c:1083
#5 0x0000555555e060a2 in coroutine_trampoline (i0=-669165424, i1=32767)
at util/coroutine-ucontext.c:116
#6 0x00007fffef4f5600 in __start_context () at /lib64/libc.so.6
#7 0x0000000000000000 in ()
(gdb)
The fix is to take the path write lock when calling v9fs_complete_rename(),
like in v9fs_rename().
Impact: DoS triggered by unprivileged guest users.
Fixes: CVE-2018-19489
Cc: P J P <ppandit@redhat.com>
Reported-by: zhibin hu <noirfate@gmail.com>
Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Greg Kurz <groug@kaod.org>
(cherry picked from commit 1d20398694a3b67a388d955b7a945ba4aa90a8a8)
commit 9af9c1c20e313f597168e0522f5fc8d78123b0c8
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Tue Nov 20 19:41:48 2018 +0100
nvme: fix out-of-bounds access to the CMB
Because the CMB BAR has a min_access_size of 2, if you read the last
byte it will try to memcpy *2* bytes from n->cmbuf, causing an off-by-one
error. This is CVE-2018-16847.
Another way to fix this might be to register the CMB as a RAM memory
region, which would also be more efficient. However, that might be a
change for big-endian machines; I didn't think this through and I don't
know how real hardware works. Add a basic testcase for the CMB in case
somebody does this change later on.
Cc: Keith Busch <keith.busch@intel.com>
Cc: qemu-block@nongnu.org
Reported-by: Li Qiang <liq3ea@gmail.com>
Reviewed-by: Li Qiang <liq3ea@gmail.com>
Tested-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 87ad860c622cc8f8916b5232bd8728c08f938fce)
commit c50c704a6a09554925b926c0313280be4a3d7100
Author: Greg Kurz <groug@kaod.org>
Date: Tue Nov 20 13:00:35 2018 +0100
9p: take write lock on fid path updates (CVE-2018-19364)
Recent commit 5b76ef50f62079a fixed a race where v9fs_co_open2() could
possibly overwrite a fid path with v9fs_path_copy() while it is being
accessed by some other thread, ie, use-after-free that can be detected
by ASAN with a custom 9p client.
It turns out that the same can happen at several locations where
v9fs_path_copy() is used to set the fid path. The fix is again to
take the write lock.
Fixes CVE-2018-19364.
Cc: P J P <ppandit@redhat.com>
Reported-by: zhibin hu <noirfate@gmail.com>
Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Greg Kurz <groug@kaod.org>
(cherry picked from commit 5b3c77aa581ebb215125c84b0742119483571e55)
commit 03c28544a1b67fd48ef1fa72231818efa8563874
Author: Roger Pau Monne <roger.pau@citrix.com>
Date: Mon Mar 18 18:37:31 2019 +0100
xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored
Or if it's not possible to honor the hinted address an error is returned
instead. This makes it easier to spot the actual failure, instead of
failing later on when the caller of xen_remap_bucket realizes the
mapping has not been created at the requested address.
Also note that at least on FreeBSD using MAP_FIXED will cause mmap to
try harder to honor the passed address.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Igor Druzhinin <igor.druzhinin@cirtix.com>
Message-Id: <20190318173731.14494-1-roger.pau@citrix.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
(cherry picked from commit 4158e93f4aced247c8db94a0275fc027da7dc97e)
commit a35ed1444329599f2975512c82be795f8af284d5
Author: Michael McConville <mmcco@mykolab.com>
Date: Fri Dec 1 11:31:57 2017 -0700
mmap(2) returns MAP_FAILED, not NULL, on failure
Signed-off-by: Michael McConville <mmcco@mykolab.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit ab1ce9bd4897b9909836e2d50bca86f2f3f2dddc)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [qemu-upstream-4.11-testing test] 137100: regressions - FAIL
@ 2019-06-03 9:34 ` Jan Beulich
0 siblings, 0 replies; 6+ messages in thread
From: Jan Beulich @ 2019-06-03 9:34 UTC (permalink / raw)
To: Julien Grall, Anthony Perard, osstest service owner; +Cc: xen-devel
>>> On 01.06.19 at 10:43, <osstest-admin@xenproject.org> wrote:
> flight 137100 qemu-upstream-4.11-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/137100/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-arm64-pvops <job status> broken in 134504
> build-arm64-xsm <job status> broken in 134504
> build-arm64 <job status> broken in 134504
> build-arm64-xsm 4 host-install(4) broken in 134504 REGR. vs. 125575
> build-arm64 4 host-install(4) broken in 134504 REGR. vs. 125575
> build-arm64-pvops 4 host-install(4) broken in 134504 REGR. vs. 125575
> test-arm64-arm64-xl 7 xen-boot fail REGR. vs. 125575
> test-arm64-arm64-libvirt-xsm 7 xen-boot fail REGR. vs. 125575
> test-arm64-arm64-xl-credit2 7 xen-boot fail REGR. vs. 125575
> test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 125575
What is the situation here? When can we expect to be able to get
4.11.2 out the door?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xen-devel] [qemu-upstream-4.11-testing test] 137100: regressions - FAIL
@ 2019-06-03 9:34 ` Jan Beulich
0 siblings, 0 replies; 6+ messages in thread
From: Jan Beulich @ 2019-06-03 9:34 UTC (permalink / raw)
To: Julien Grall, Anthony Perard, osstest service owner; +Cc: xen-devel
>>> On 01.06.19 at 10:43, <osstest-admin@xenproject.org> wrote:
> flight 137100 qemu-upstream-4.11-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/137100/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-arm64-pvops <job status> broken in 134504
> build-arm64-xsm <job status> broken in 134504
> build-arm64 <job status> broken in 134504
> build-arm64-xsm 4 host-install(4) broken in 134504 REGR. vs. 125575
> build-arm64 4 host-install(4) broken in 134504 REGR. vs. 125575
> build-arm64-pvops 4 host-install(4) broken in 134504 REGR. vs. 125575
> test-arm64-arm64-xl 7 xen-boot fail REGR. vs. 125575
> test-arm64-arm64-libvirt-xsm 7 xen-boot fail REGR. vs. 125575
> test-arm64-arm64-xl-credit2 7 xen-boot fail REGR. vs. 125575
> test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 125575
What is the situation here? When can we expect to be able to get
4.11.2 out the door?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [qemu-upstream-4.11-testing test] 137100: regressions - FAIL
@ 2019-06-03 13:47 ` Julien Grall
0 siblings, 0 replies; 6+ messages in thread
From: Julien Grall @ 2019-06-03 13:47 UTC (permalink / raw)
To: Jan Beulich, Anthony Perard, osstest service owner
Cc: xen-devel, Stefano Stabellini
Hi Jan,
On 03/06/2019 10:34, Jan Beulich wrote:
>>>> On 01.06.19 at 10:43, <osstest-admin@xenproject.org> wrote:
>> flight 137100 qemu-upstream-4.11-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/137100/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>> build-arm64-pvops <job status> broken in 134504
>> build-arm64-xsm <job status> broken in 134504
>> build-arm64 <job status> broken in 134504
>> build-arm64-xsm 4 host-install(4) broken in 134504 REGR. vs. 125575
>> build-arm64 4 host-install(4) broken in 134504 REGR. vs. 125575
>> build-arm64-pvops 4 host-install(4) broken in 134504 REGR. vs. 125575
>> test-arm64-arm64-xl 7 xen-boot fail REGR. vs. 125575
>> test-arm64-arm64-libvirt-xsm 7 xen-boot fail REGR. vs. 125575
>> test-arm64-arm64-xl-credit2 7 xen-boot fail REGR. vs. 125575
>> test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 125575
>
> What is the situation here? When can we expect to be able to get
> 4.11.2 out the door?
I haven't seen anyone replying my e-mail [1] sent 14 days ago.
Cheers,
[1] https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg01771.html
>
> Jan
>
>
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xen-devel] [qemu-upstream-4.11-testing test] 137100: regressions - FAIL
@ 2019-06-03 13:47 ` Julien Grall
0 siblings, 0 replies; 6+ messages in thread
From: Julien Grall @ 2019-06-03 13:47 UTC (permalink / raw)
To: Jan Beulich, Anthony Perard, osstest service owner
Cc: xen-devel, Stefano Stabellini
Hi Jan,
On 03/06/2019 10:34, Jan Beulich wrote:
>>>> On 01.06.19 at 10:43, <osstest-admin@xenproject.org> wrote:
>> flight 137100 qemu-upstream-4.11-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/137100/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>> build-arm64-pvops <job status> broken in 134504
>> build-arm64-xsm <job status> broken in 134504
>> build-arm64 <job status> broken in 134504
>> build-arm64-xsm 4 host-install(4) broken in 134504 REGR. vs. 125575
>> build-arm64 4 host-install(4) broken in 134504 REGR. vs. 125575
>> build-arm64-pvops 4 host-install(4) broken in 134504 REGR. vs. 125575
>> test-arm64-arm64-xl 7 xen-boot fail REGR. vs. 125575
>> test-arm64-arm64-libvirt-xsm 7 xen-boot fail REGR. vs. 125575
>> test-arm64-arm64-xl-credit2 7 xen-boot fail REGR. vs. 125575
>> test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 125575
>
> What is the situation here? When can we expect to be able to get
> 4.11.2 out the door?
I haven't seen anyone replying my e-mail [1] sent 14 days ago.
Cheers,
[1] https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg01771.html
>
> Jan
>
>
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-06-03 13:48 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-01 8:43 [qemu-upstream-4.11-testing test] 137100: regressions - FAIL osstest service owner
2019-06-01 8:43 ` [Xen-devel] " osstest service owner
2019-06-03 9:34 ` Jan Beulich
2019-06-03 9:34 ` [Xen-devel] " Jan Beulich
2019-06-03 13:47 ` Julien Grall
2019-06-03 13:47 ` [Xen-devel] " Julien Grall
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.