Upgrade version to 4.2.1.tizen20240418

Change-Id: I8cf1b38cc7f7061f5c37341e25f28e383f803e3f

Merge branch 'sandbox/xuwc/devel-riscv-py2' into devel-py2

Change-Id: I4afa9c5351396b4aa3a45713523b38de970dbe4a
Signed-off-by: wanchao-xu <wanchao.xu@samsung.com>

Fix the build error on opensuse42.1
  * glib2-devel version is 2.44 on opensuse.

Change-Id: I390ae0a0c42f4b187f7e7929ee437172f3bf834c

Fix the install error of debian and packaging.

Change-Id: I03f7edd406f1845ecebef08fd78c1a979c09d745
Signed-off-by: wanchao-xu <wanchao.xu@samsung.com>

Update debian and packaging

Change-Id: I8df3ead2d1f3a5207b3327159bdcaa0337a541cb
Signed-off-by: wanchao-xu <wanchao.xu@samsung.com>

tcg: use QTree instead of GTree

qemu-user can hang in a multi-threaded fork. One common
reason is that when creating a TB, between fork and exec
we manipulate a GTree whose memory allocator (GSlice) is
not fork-safe.

Although POSIX does not mandate it, the system's allocator
(e.g. tcmalloc, libc malloc) is probably fork-safe.

Fix some of these hangs by using QTree, which uses the system's
allocator regardless of the Glib version that we used at
configuration time.

Tested with the test program in the original bug report, i.e.:

Fixes: #285
Change-Id: I61bbe16ee5b639615a54f5afad0fa084c63c9b42
Signed-off-by: Emilio Cota <cota@braap.org>

util: import GTree as QTree

The only reason to add this implementation is to control the memory allocator
used. Some users (e.g. TCG) cannot work reliably in multi-threaded
environments (e.g. forking in user-mode) with GTree's allocator, GSlice.
See https://gitlab.com/qemu-project/qemu/-/issues/285 for details.

Importing GTree is a temporary workaround until GTree migrates away
from GSlice.

This implementation is identical to that in glib v2.75.0, except that
we don't import recent additions to the API nor deprecated API calls,
none of which are used in QEMU.

I've imported tests from glib and added a benchmark just to
make sure that performance is similar. Note: it cannot be identical
because (1) we are not using GSlice, (2) we use different compilation flags
(e.g. -fPIC) and (3) we're linking statically.

$ cat /proc/cpuinfo| grep 'model name' | head -1
model name      : AMD Ryzen 7 PRO 5850U with Radeon Graphics
$ echo '0' | sudo tee /sys/devices/system/cpu/cpufreq/boost
$ tests/bench/qtree-bench

 Tree         Op      32            1024            4096          131072
 1048576
------------------------------------------------------------------------------------------------
GTree     Lookup   83.23           43.08           25.31           19.40
   16.22
QTree     Lookup  113.42 (1.36x)   53.83 (1.25x)   28.38 (1.12x)   17.64
(0.91x)   13.04 (0.80x)
GTree     Insert   44.23           29.37           25.83           19.49
   17.03
QTree     Insert   46.87 (1.06x)   25.62 (0.87x)   24.29 (0.94x)   16.83
(0.86x)   12.97 (0.76x)
GTree     Remove   53.27           35.15           31.43           24.64
   16.70
QTree     Remove   57.32 (1.08x)   41.76 (1.19x)   38.37 (1.22x)   29.30
(1.19x)   15.07 (0.90x)
GTree  RemoveAll  135.44          127.52          126.72          120.11
   64.34
QTree  RemoveAll  127.15 (0.94x)  110.37 (0.87x)  107.97 (0.85x)   97.13
(0.81x)   55.10 (0.86x)
GTree   Traverse  277.71          276.09          272.78          246.72
   98.47
QTree   Traverse  370.33 (1.33x)  411.97 (1.49x)  400.23 (1.47x)  262.82
(1.07x)   78.52 (0.80x)
------------------------------------------------------------------------------------------------

As a sanity check, the same benchmark when Glib's version
is >=  (i.e. QTree == GTree):

 Tree         Op      32            1024            4096          131072
 1048576
------------------------------------------------------------------------------------------------
GTree     Lookup   82.72           43.09           24.18           19.73
   16.09
QTree     Lookup   81.82 (0.99x)   43.10 (1.00x)   24.20 (1.00x)   19.76
(1.00x)   16.26 (1.01x)
GTree     Insert   45.07           29.62           26.34           19.90
   17.18
QTree     Insert   45.72 (1.01x)   29.60 (1.00x)   26.38 (1.00x)   19.71
(0.99x)   17.20 (1.00x)
GTree     Remove   54.48           35.36           31.77           24.97
   16.95
QTree     Remove   54.46 (1.00x)   35.32 (1.00x)   31.77 (1.00x)   24.91
(1.00x)   17.15 (1.01x)
GTree  RemoveAll  140.68          127.36          125.43          121.45
   68.20
QTree  RemoveAll  140.65 (1.00x)  127.64 (1.00x)  125.01 (1.00x)  121.73
(1.00x)   67.06 (0.98x)
GTree   Traverse  278.68          276.05          266.75          251.65
  104.93
QTree   Traverse  278.31 (1.00x)  275.78 (1.00x)  266.42 (1.00x)  247.89
(0.99x)  104.58 (1.00x)
------------------------------------------------------------------------------------------------

Related: #285

Change-Id: I5eee4511a911a39a9c4739fee3df78d8d0414233
Signed-off-by: Emilio Cota <cota@braap.org>

Fix .NET SEHException issue refer to https://gitlab.com/qemu-project/qemu/-/issues/271

Change-Id: Ia8218fd963075448b55b7a5a705c6f35a722ada4
Signed-off-by: biao716.wang <biao716.wang@samsung.com>

binfmt: translate symbolic links correctly with realpath

Change-Id: Ic0eeac9de40a8e1082c83b442829ac28f68bff04
Signed-off-by: Julien Isorce <j.isorce@samsung.com>
Signed-off-by: Yury Usishchev <y.usishchev@samsung.com>

Remove imported patches from packaging.

Change-Id: I55df320a869c984bdc7eb1f80aa5a4f3f0466d46

Enable cross compile prefix for C compiler invocation

Signed-off-by: Bruce Rogers <brogers@suse.com>

ensure headers included are compatible with freestanding mode

Certain standard headers are designated for use in freestanding mode
while others are prohibited. To conform to these rules, use <stdint.h>
instead of <inttypes.h> as well as switch one <string.h> reference to
the "string.h" implemented in project.

Signed-off-by: Bruce Rogers <brogers@suse.com>

dhcp: Always send DHCP_OPT_LEN bytes in options

Git-commit: d7fb54218424c3b2517aee5b391ced0f75386a5d
References: bsc#1187364, CVE-2021-3592

RFC2131 suggests that the options field may be at least 312 bytes.
Some DHCP clients seem to assume that it has to be at least 312 bytes.

Fixes #51
Fixes: f13cad45b25d92760bb0ad67bec0300a4d7d5275 ("bootp: limit
vendor-specific area to input packet memory buffer")

Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Jose R Ziviani <jose.ziviani@suse.com>

udp: check upd_input buffer size

Git-commit: 74572be49247c8c5feae7c6e0b50c4f569ca9824
References: bsc#1187367, CVE-2021-3594

Fixes: CVE-2021-3594
Fixes: https://gitlab.freedesktop.org/slirp/libslirp/-/issues/47
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Jose R Ziviani <jose.ziviani@suse.com>

tftp: introduce a header structure

Git-commit: 990163cf3ac86b7875559f49602c4d76f46f6f30
References: bsc#1187366, CVE-2021-3595

Instead of using a composed structure and potentially reading past the
incoming buffer, use a different structure for the header.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Jose R Ziviani <jose.ziviani@suse.com>

tftp: check tftp_input buffer size

Git-commmit: 3f17948137155f025f7809fdc38576d5d2451c3d
References: bsc#1187366, CVE-2021-3595

Fixes: CVE-2021-3595
Fixes: https://gitlab.freedesktop.org/slirp/libslirp/-/issues/46
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Jose R Ziviani <jose.ziviani@suse.com>

upd6: check udp6_input buffer size

Git-commit: de71c15de66ba9350bf62c45b05f8fbff166517b
References: bsc#1187365, CVE-2021-3593

Fixes: CVE-2021-3593
Fixes: https://gitlab.freedesktop.org/slirp/libslirp/-/issues/45
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Jose R Ziviani <jose.ziviani@suse.com>

bootp: check bootp_input buffer size

Git-commit: 2eca0838eee1da96204545e22cdaed860d9d7c6c
References: bsc#1187364, CVE-2021-3592

Fixes: CVE-2021-3592
Fixes: https://gitlab.freedesktop.org/slirp/libslirp/-/issues/44
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Jose R Ziviani <jose.ziviani@suse.com>

bootp: limit vendor-specific area to input packet memory buffer

Git-commit: f13cad45b25d92760bb0ad67bec0300a4d7d5275
References: bsc#1187364, CVE-2021-3592

sizeof(bootp_t) currently holds DHCP_OPT_LEN. Remove this optional field
from the structure, to help with the following patch checking for
minimal header size. Modify the bootp_reply() function to take the
buffer boundaries and avoiding potential buffer overflow.

Related to CVE-2021-3592.

https://gitlab.freedesktop.org/slirp/libslirp/-/issues/44

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Jose R Ziviani <jose.ziviani@suse.com>

Add mtod_check()

Git-commit: 93e645e72a056ec0b2c16e0299fc5c6b94e4ca17
References: bsc#1187364, CVE-2021-3592
            bsc#1187367, CVE-2021-3594

Recent security issues demonstrate the lack of safety care when casting
a mbuf to a particular structure type. At least, it should check that
the buffer is large enough. The following patches will make use of this
function.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Jose R Ziviani <jose.ziviani@suse.com>

Drop bogus IPv6 messages

Git-commit: c7ede54cbd2e2b25385325600958ba0124e31cc0
References: bsc#1172380 CVE-2020-10756

Drop IPv6 message shorter than what's mentioned in the payload
length header (+ the size of the IPv6 header). They're invalid an could
lead to data leakage in icmp6_send_echoreply().

Signed-off-by: Jose R Ziviani <jose.ziviani@suse.com>

slirp: check pkt_len before reading protocol header

Git-commit: 2e1dcbc0c2af64fcb17009eaf2ceedd81be2b27f
References: bsc#1179466, bsc#1179467

While processing ARP/NCSI packets in 'arp_input' or 'ncsi_input'
routines, ensure that pkt_len is large enough to accommodate the
respective protocol headers, lest it should do an OOB access.
Add check to avoid it.

CVE-2020-29129 CVE-2020-29130
  QEMU: slirp: out-of-bounds access while processing ARP/NCSI packets
 -> https://www.openwall.com/lists/oss-security/2020/11/27/1

Reported-by: Qiuhao Li <Qiuhao.Li@outlook.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Message-Id: <20201126135706.273950-1-ppandit@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Bruce Rogers <brogers@suse.com>

Make keycode-gen output reproducible (use SOURCE_DATE_EPOCH timestamp)

Signed-off-by: Bruce Rogers <brogers@suse.com

roms/sgabios: Fix csum8 to be built by host compiler

Signed-off-by: Bruce Rogers <brogers@suse.com

sgabios:Makefile: fix issues of build reproducibility

It is desirable to produce the same bits on subsequent
builds when the actual code of the package doesn't
change. (bsc#1011213)

Signed-off-by: Bruce Rogers <brogers@suse.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>

Workaround compilation error with gcc 9.1

References: bsc#1121464

Compiling with gcc 9.1 generates lots of "taking address of packed
member of ... may result in an unaligned pointer value" warnings.

Some of these warnings are genuine, and indicate correctly that parts
of iPXE currently require the CPU (or runtime environment) to support
unaligned accesses.  For example: the TCP/IP receive data path will
attempt to access 32-bit fields that may not be aligned to a 32-bit
boundary.

Other warnings are either spurious (such as when the pointer is to a
variable-length byte array, which can have no alignment requirement
anyway) or unhelpful (such as when the pointer is used solely to
provide a debug colour value for the DBGC() macro).

There appears to be no easy way to silence the spurious warnings.
Since the ability to perform unaligned accesses is already a
requirement for iPXE, work around the problem by silencing this class
of warnings.

Signed-off-by: Valentine Barshak <gvaxon@gmail.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Bruce Rogers <brogers@suse.com>

Fix "'%s' directive argument is null" error

Git-commit: 412acd7854de10e7194f362a6b1a3257a17974f7
References: bsc#1121464

Use '%p' directive, and print handle's address if the address is null
and the handle doesn't have a name.  This fixes the following
compilation error:

  interface/efi/efi_debug.c:334:3: error: '%s' directive
  argument is null [-Werror=format-overflow=]

Signed-off-by: Valentine Barshak <gvaxon@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Bruce Rogers <brogers@suse.com>

ipxe:Makefile: fix issues of build reproducibility

References: bsc#1011213

It is desirable to produce the same bits on subsequent
builds when the actual code of the package doesn't
change. (bsc#1011213)

Signed-off-by: Bruce Rogers <brogers@suse.com>

stub out the SAN req's in int13

Include-If: %if 0%{?patch-possibly-applied-elsewhere}

We need to find some code or data to change so we can make the rom fit
into the legacy size requirements. Comment out SAN support, and
hopefully nobody will be impacted.

Signed-off-by: Bruce Rogers <brogers@suse.com>

vga: fix cirrus bios

Git-commit: d11c75185276ded944f2ea0277532b7fee849bbc

Little mistake, big effect.  The patch adding the ati driver broke
cirrus due to a missing "else", which effectively downgrades cirrus
to standard vga.

Fixes: 34b6ecc16074 ("vga: add atiext driver")
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Bruce Rogers <brogers@suse.com>

enable cross compilation on ARM

Signed-off-by: Bruce Rogers <brogers@suse.com>

seabios: switch to python3 as needed

Switch to python3 the places where "python2" is explicitly referenced.
(Ignore the uses of #!/usr/bin/env python, since that usage does the
right thing in our build environment).
Include changes proposed by the python3 2to3 tool.

Signed-off-by: Bruce Rogers <brogers@suse.com>

seabios: use python2 explicitly as needed

Switch to python2 the places where "python" is explicitly referenced.
(Ignore the uses of #!/usr/bin/env python, since that usage does the
right thing in our build environment).

Signed-off-by: Bruce Rogers <brogers@suse.com>

uas: add stream number sanity checks.

Git-commit: 13b250b12ad3c59114a6a17d59caf073ce45b33a
References: bsc#1189702 CVE-2021-3713

The device uses the guest-supplied stream number unchecked, which can
lead to guest-triggered out-of-band access to the UASDevice->data3 and
UASDevice->status3 fields.  Add the missing checks.

Fixes: CVE-2021-3713
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reported-by: Chen Zhe <chenzhe@huawei.com>
Reported-by: Tan Jingguo <tanjingguo@huawei.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210818120505.1258262-2-kraxel@redhat.com>
Signed-off-by: Jose R Ziviani <jose.ziviani@suse.com>

virtio-net: fix use after unmap/free for sg

Git-commit: bedd7e93d01961fcb16a97ae45d93acf357e11f6
References: bsc#1189938 CVE-2021-3748

When mergeable buffer is enabled, we try to set the num_buffers after
the virtqueue elem has been unmapped. This will lead several issues,
E.g a use after free when the descriptor has an address which belongs
to the non direct access region. In this case we use bounce buffer
that is allocated during address_space_map() and freed during
address_space_unmap().

Fixing this by storing the elems temporarily in an array and delay the
unmap after we set the the num_buffers.

This addresses CVE-2021-3748.

Reported-by: Alexander Bulekov <alxndr@bu.edu>
Fixes: fbe78f4f55c6 ("virtio-net support")
Cc: qemu-stable@nongnu.org
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Jose R Ziviani <jose.ziviani@suse.com>

file-posix: try BLKSECTGET on block devices too, do not round to power of 2

Git-commit: 18473467d55a20d643b6c9b3a52de42f705b4d35
References: bsc#1190425

bs->sg is only true for character devices, but block devices can also
be used with scsi-block and scsi-generic.  Unfortunately BLKSECTGET
returns bytes in an int for /dev/sgN devices, and sectors in a short
for block devices, so account for that in the code.

The maximum transfer also need not be a power of 2 (for example I have
seen disks with 1280 KiB maximum transfer) so there's no need to pass
the result through pow2floor.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

block: add max_hw_transfer to BlockLimits

Git-commit: 24b36e9813ec15da7db62e3b3621730710c5f020
References: bsc#1190425

For block host devices, I/O can happen through either the kernel file
descriptor I/O system calls (preadv/pwritev, io_submit, io_uring)
or the SCSI passthrough ioctl SG_IO.

In the latter case, the size of each transfer can be limited by the
HBA, while for file descriptor I/O the kernel is able to split and
merge I/O in smaller pieces as needed.  Applying the HBA limits to
file descriptor I/O results in more system calls and suboptimal
performance, so this patch splits the max_transfer limit in two:
max_transfer remains valid and is used in general, while max_hw_transfer
is limited to the maximum hardware size.  max_hw_transfer can then be
included by the scsi-generic driver in the block limits page, to ensure
that the stricter hardware limit is used.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

block-backend: align max_transfer to request alignment

Git-commit: b99f7fa08a3df8b8a6a907642e5851cdcf43fa9f
References: bsc#1190425

Block device requests must be aligned to bs->bl.request_alignment.
It makes sense for drivers to align bs->bl.max_transfer the same
way; however when there is no specified limit, blk_get_max_transfer
just returns INT_MAX.  Since the contract of the function does not
specify that INT_MAX means "no maximum", just align the outcome
of the function (whether INT_MAX or bs->bl.max_transfer) before
returning it.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

osdep: provide ROUND_DOWN macro

Git-commit: c9797456f64ce72c03eb2969d97ac1dd4698d91e
References: bsc#1190425

osdep.h provides a ROUND_UP macro to hide bitwise operations for the
purpose of rounding a number up to a power of two; add a ROUND_DOWN
macro that does the same with truncation towards zero.

While at it, change the formatting of some comments.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

scsi-generic: pass max_segments via max_iov field in BlockLimits

Git-commit: 01ef8185b809af9d287e1a03a3f9d8ea8231118a
References: bsc#1190425

I/O to a disk via read/write is not limited by the number of segments allowed
by the host adapter; the kernel can split requests if needed, and the limit
imposed by the host adapter can be very low (256k or so) to avoid that SG_IO
returns EINVAL if memory is heavily fragmented.

Since this value is only interesting for SG_IO-based I/O, do not include
it in the max_transfer and only take it into account when patching the
block limits VPD page in the scsi-generic device.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

file-posix: fix max_iov for /dev/sg devices

Git-commit: 8ad5ab6148dca8aad297c134c09c84b0b92d45ed
References: bsc#1190425

Even though it was only called for devices that have bs->sg set (which
must be character devices), sg_get_max_segments looked at /sys/dev/block
which only works for block devices.

On Linux the sg driver has its own way to provide the maximum number of
iovecs in a scatter/gather list, so add support for it.  The block device
path is kept because it will be reinstated in the next patches.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

xen: remove BlockBackend object reference in xen_block_unrealize

References: bsc#1189234

Signed-off-by: Lin Ma <lma@suse.com>

usbredir: fix free call

Git-commit: 5e796671e6b8d5de4b0b423dce1b3eba144a92c9
References: bsc#1189145 CVE-2021-3682

data might point into the middle of a larger buffer, there is a separate
free_on_destroy pointer passed into bufp_alloc() to handle that.  It is
only used in the normal workflow though, not when dropping packets due
to the queue being full.  Fix that.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/491
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20210722072756.647673-1-kraxel@redhat.com>
Signed-off-by: Jose R Ziviani <jose.ziviani@suse.com>

usb: limit combined packets to 1 MiB (CVE-2021-3527)

Git-commit: 05a40b172e4d691371534828078be47e7fff524c
References: bsc#1186012, CVE-2021-3527

usb-host and usb-redirect try to batch bulk transfers by combining many
small usb packets into a single, large transfer request, to reduce the
overhead and improve performance.

This patch adds a size limit of 1 MiB for those combined packets to
restrict the host resources the guest can bind that way.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-Id: <20210503132915.2335822-6-kraxel@redhat.com>
Signed-off-by: Jose R Ziviani <jose.ziviani@suse.com>

usb/mtp: avoid dynamic stack allocation

Git-commit: 06aa50c06c6392084244f8169d34b8e2d9c43ef2
References: bsc#1186012, CVE-2021-3527

Use autofree heap allocation instead.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210503132915.2335822-4-kraxel@redhat.com>
Signed-off-by: Jose R Ziviani <jose.ziviani@suse.com>

usb/redir: avoid dynamic stack allocation (CVE-2021-3527)

Git-commit: 7ec54f9eb62b5d177e30eb8b1cad795a5f8d8986
References: bsc#1186012, CVE-2021-3527

Use autofree heap allocation instead.

Fixes: 4f4321c11ff ("usb: use iovecs in USBPacket")
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210503132915.2335822-3-kraxel@redhat.com>
Signed-off-by: Jose R Ziviani <jose.ziviani@suse.com>

usb/hid: avoid dynamic stack allocation

Git-commit: 3f67e2e7f135b8be4117f3c2960e78d894feaa03
References: bsc#1186012, CVE-2021-3527

Use autofree heap allocation instead.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210503132915.2335822-2-kraxel@redhat.com>
Signed-off-by: Jose R Ziviani <jose.ziviani@suse.com>

hw/usb/host-stub: Remove unused header

Git-commit: 1081607bfab94a0b6149c4a2195737107aed265f
References: bsc#1186012, CVE-2021-3527

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20210424224110.3442424-2-f4bug@amsat.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Jose R Ziviani <jose.ziviani@suse.com>

net: eepro100: validate various address values

Git-commit: 000000000000000000000000000000000000000000000
References: bsc#1182651, CVE-2021-20255

Patch based on discussion:
https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg06098.html

While processing controller commands, eepro100 emulator gets
command unit(CU) base address OR receive unit (RU) base address
OR command block (CB) address from guest. If these values are not
checked, it may lead to an infinite loop kind of issues. Add checks
to avoid it.

Reported-by: Ruhr-University Bochum <bugs-syssec@rub.de>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Acked-By: Jose R Ziviani <jose.ziviani@suse.com>

hw/scsi/megasas: check for NULL frame in megasas_command_cancelled()

Git-commit: 00000000000000000000000000000000000000000000
References: bsc#1180432, CVE-2020-35503

Ensure that 'cmd->frame' is not NULL before accessing the 'header' field.
This check prevents a potential NULL pointer dereference issue.

RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1910346
Signed-off-by: Mauro Matteo Cascella <mcascell@redhat.com>
Reported-by: Cheolwoo Myung <cwmyung@snu.ac.kr>
Acked-By: Jose R Ziviani <jose.ziviani@suse.com>

esp: ensure that do_cmd is set to zero before submitting an ESP select command

Git-commit: 607206948cacda4a80be5b976dba490970a18a76
References: bsc#1180433, CVE-2020-35504
            bsc#1180434, CVE-2020-35505
            bsc#1180435, CVE-2020-35506

When a CDB has been received and is about to be submitted to the SCSI layer
via one of the ESP select commands, ensure that do_cmd is set to zero before
executing the command.

Otherwise a guest executing 2 valid CDBs in quick sequence can invoke the SCSI
.transfer_data callback again before do_cmd is set to zero by the callback
function triggering an assert at the start of esp_transfer_data().

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20210407195801.685-12-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Jose R Ziviani <jose.ziviani@suse.com>

esp: don't reset async_len directly in esp_select() if cancelling request

Git-commit: 324c8809897c8c53ad05c3a7147d272f1711cd5e
References: bsc#1180433, CVE-2020-35504
            bsc#1180434, CVE-2020-35505
            bsc#1180435, CVE-2020-35506

Instead let the SCSI layer invoke the .cancel callback itself to cancel and
reset the request state.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Tested-by: Alexander Bulekov <alxndr@bu.edu>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20210407195801.685-11-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Jose R Ziviani <jose.ziviani@suse.com>

esp: ensure cmdfifo is not empty and current_dev is non-NULL

Git-commit: 99545751734035b76bd372c4e7215bb337428d89
References: bsc#1180433, CVE-2020-35504
            bsc#1180434, CVE-2020-35505
            bsc#1180435, CVE-2020-35506

When about to execute a SCSI command, ensure that cmdfifo is not empty and
current_dev is non-NULL. This can happen if the guest tries to execute a TI
(Transfer Information) command without issuing one of the select commands
first.

Buglink: https://bugs.launchpad.net/qemu/+bug/1910723
Buglink: https://bugs.launchpad.net/qemu/+bug/1909247
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: Alexander Bulekov <alxndr@bu.edu>
Message-Id: <20210407195801.685-7-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Jose R Ziviani <jose.ziviani@suse.com>

esp: always check current_req is not NULL before use in DMA callbacks

Git-commit: 0db895361b8a82e1114372ff9f4857abea605701
References: bsc#1180433, CVE-2020-35504
            bsc#1180434, CVE-2020-35505
            bsc#1180435, CVE-2020-35506

After issuing a SCSI command the SCSI layer can call the SCSIBusInfo .cancel
callback which resets both current_req and current_dev to NULL. If any data
is left in the transfer buffer (async_len != 0) then the next TI (Transfer
Information) command will attempt to reference the NULL pointer causing a
segfault.

Buglink: https://bugs.launchpad.net/qemu/+bug/1910723
Buglink: https://bugs.launchpad.net/qemu/+bug/1909247
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Tested-by: Alexander Bulekov <alxndr@bu.edu>
Message-Id: <20210407195801.685-2-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Jose R Ziviani <jose.ziviani@suse.com>

pvrdma: Fix the ring init error flow (CVE-2021-3608)

Git-commit: 66ae37d8cc313f89272e711174a846a229bcdbd3
References: CVE-2021-3608 bsc#1187538

Do not unmap uninitialized dma addresses.

Fixes: CVE-2021-3608
Reviewed-by: VictorV (Kunlun Lab) <vv474172261@gmail.com>
Tested-by: VictorV (Kunlun Lab) <vv474172261@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel@redhat.com>
Message-Id: <20210630115246.2178219-1-marcel@redhat.com>
Tested-by: Yuval Shaia <yuval.shaia.ml@gmail.com>
Reviewed-by: Yuval Shaia <yuval.shaia.ml@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Signed-off-by: Jose R. Ziviani <jziviani@suse.de>

pvrdma: Ensure correct input on ring init (CVE-2021-3607)

Git-commit: 32e5703cfea07c91e6e84bcb0313f633bb146534
References: CVE-2021-3607 bsc#1187539

Check the guest passed a non zero page count
for pvrdma device ring buffers.

Fixes: CVE-2021-3607
Reported-by: VictorV (Kunlun Lab) <vv474172261@gmail.com>
Reviewed-by: VictorV (Kunlun Lab) <vv474172261@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel@redhat.com>
Message-Id: <20210630114634.2168872-1-marcel@redhat.com>
Reviewed-by: Yuval Shaia <yuval.shaia.ml@gmail.com>
Tested-by: Yuval Shaia <yuval.shaia.ml@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Signed-off-by: Jose R. Ziviani <jziviani@suse.de>

hw/rdma: Fix possible mremap overflow in the pvrdma device (CVE-2021-3582)

Git-commit: 284f191b4abad213aed04cb0458e1600fd18d7c4
References: CVE-2021-3582 bsc#1187499

Ensure mremap boundaries not trusting the guest kernel to
pass the correct buffer length.

Fixes: CVE-2021-3582
Reported-by: VictorV (Kunlun Lab) <vv474172261@gmail.com>
Tested-by: VictorV (Kunlun Lab) <vv474172261@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel@redhat.com>
Message-Id: <20210616110600.20889-1-marcel.apfelbaum@gmail.com>
Reviewed-by: Yuval Shaia <yuval.shaia.ml@gmail.com>
Tested-by: Yuval Shaia <yuval.shaia.ml@gmail.com>
Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Signed-off-by: Jose R. Ziviani <jziviani@suse.de>

qom: code hardening - have bound checking while looping with integer value

Git-commit: 1bf8b88f144bee747e386c88d45d772e066bbb36
References: bsc#1187529 CVE-2021-3611

Object property insertion code iterates over an integer to get an unused
index that can be used as an unique name for an object property. This loop
increments the integer value indefinitely. Although very unlikely, this can
still cause an integer overflow.
In this change, we fix the above code by checking against INT16_MAX and making
sure that the interger index does not overflow beyond that value. If no
available index is found, the code would cause an assertion failure. This
assertion failure is necessary because the callers of the function do not check
the return value for NULL.

Signed-off-by: Ani Sinha <ani@anisinha.ca>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20200921093325.25617-1-ani@anisinha.ca>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Cho, Yu-Chen <acho@suse.com>

qemu-iotests, qtest: rewrite test 067 as a qtest

Git-commit: d8a18da56df93b7f778fb97ba370031597d19ffd
References: bsc#1184574

Test 067 from qemu-iotests is executing QMP commands to hotplug
and hot-unplug disks, devices and blockdevs.  Because the power
of the text-based test harness is limited, it is actually limiting
the checks that it does, for example by skipping DEVICE_DELETED
events.

tests/qtest already has a similar test, drive_del-test.c.
We can merge them, and even reuse some of the existing code in
drive_del-test.c.  This will improve the quality of the test by
covering DEVICE_DELETED events and testing multiple architectures
(therefore covering multiple PCI hotplug mechanisms as well as s390x
virtio-ccw).

The only difference is that the new test will always use null-co:// for
the medium rather than qcow2 or raw, but this should be irrelevant for
what the test is covering.  For example there are no "qemu-img check"
runs in 067 that would check that the file is properly closed.

The new tests requires PCI hot-plug support, so drive_del-test
is moved from qemu-system-ppc to qemu-system-ppc64.

Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

qtest: check that drives are really appearing and disappearing

Git-commit: 9a613ddccce125e4cc3a4a23c294837c906440d6
References: bsc#1184574

Do not just trust the HMP commands to create and delete the drive, use
query-block to check that this is actually the case.

Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

qtest: switch users back to qtest_qmp_receive

Git-commit: bb1a5b97f75ae209d8707f698da23088d7b9bbb5
References: bsc#1184574

Let test use the new functionality for buffering events.
The only remaining users of qtest_qmp_receive_dict are tests
that fuzz the QMP protocol.

Tested with 'make check-qtest'.

Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20201006123904.610658-4-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

device-plug-test: use qtest_qmp to send the device_del command

Git-commit: c45a70d8c271056896a057fbcdc7743a2942d0ec
References: bsc#1184574

Simplify the code now that events are buffered.  There is no need
anymore to separate sending the command and retrieving the response.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

qtest: remove qtest_qmp_receive_success

Git-commit: 5e34005571af53b73e4a10cb2c6e0712cf6b8d2c
References: bsc#1184574

The purpose of qtest_qmp_receive_success was mostly to process events
that arrived between the issueing of a command and the "return"
line from QMP.  This is now handled by the buffering of events
that libqtest performs automatically.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

qtest: Reintroduce qtest_qmp_receive with QMP event buffering

Git-commit: c22045bfe6d5ceebd414ff53ff23fff7ad5930d1
References: bsc#1184574

The new qtest_qmp_receive buffers all the received qmp events, allowing
qtest_qmp_eventwait_ref to return them.

This is intended to solve the race in regard to ordering of qmp events
vs qmp responses, as soon as the callers start using the new interface.

In addition to that, define qtest_qmp_event_ref a function which only scans
the buffer that qtest_qmp_receive stores the events to.  This is intended
for callers that are only interested in events that were received during
the last call to the qtest_qmp_receive.

Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20201006123904.610658-3-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

qtest: rename qtest_qmp_receive to qtest_qmp_receive_dict

Git-commit: 1c3e2a38de4e3094dfaf1e4dd73b1e5a91df8fe9
References: bsc#1184574

In the next patch a new version of qtest_qmp_receive will be
reintroduced that will buffer received qmp events for later
consumption in qtest_qmp_eventwait_ref

No functional change intended.

Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

tests: add migration-helpers unit

Git-commit: d77799ccda4baca822308ed1648a3c72d46cf74e
References: bsc#1184574

Move a few helper functions from migration-test.c to migration-helpers.c

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

blockjob: Fix crash with IOthread when block commit after snapshot

Git-commit: 076d467aacdf6dc5d01e2e61740b1795f2aec2f6
References: bsc#1187013

Currently, if guest has workloads, IO thread will acquire aio_context
lock before do io_submit, it leads to segmentfault when do block commit
after snapshot. Just like below:

Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread 0x7f7c7d91f700 (LWP 99907)]
0x00005576d0f65aab in bdrv_mirror_top_pwritev at ../block/mirror.c:1437
1437    ../block/mirror.c: No such file or directory.
(gdb) p s->job
$17 = (MirrorBlockJob *) 0x0
(gdb) p s->stop
$18 = false

Call trace of IO thread:
0  0x00005576d0f65aab in bdrv_mirror_top_pwritev at ../block/mirror.c:1437
1  0x00005576d0f7f3ab in bdrv_driver_pwritev at ../block/io.c:1174
2  0x00005576d0f8139d in bdrv_aligned_pwritev at ../block/io.c:1988
3  0x00005576d0f81b65 in bdrv_co_pwritev_part at ../block/io.c:2156
4  0x00005576d0f8e6b7 in blk_do_pwritev_part at ../block/block-backend.c:1260
5  0x00005576d0f8e84d in blk_aio_write_entry at ../block/block-backend.c:1476
...

Switch to qemu main thread:
0  0x00007f903be704ed in __lll_lock_wait at
/lib/../lib64/libpthread.so.0
1  0x00007f903be6bde6 in _L_lock_941 at /lib/../lib64/libpthread.so.0
2  0x00007f903be6bcdf in pthread_mutex_lock at
/lib/../lib64/libpthread.so.0
3  0x0000564b21456889 in qemu_mutex_lock_impl at
../util/qemu-thread-posix.c:79
4  0x0000564b213af8a5 in block_job_add_bdrv at ../blockjob.c:224
5  0x0000564b213b00ad in block_job_create at ../blockjob.c:440
6  0x0000564b21357c0a in mirror_start_job at ../block/mirror.c:1622
7  0x0000564b2135a9af in commit_active_start at ../block/mirror.c:1867
8  0x0000564b2133d132 in qmp_block_commit at ../blockdev.c:2768
9  0x0000564b2141fef3 in qmp_marshal_block_commit at
qapi/qapi-commands-block-core.c:346
10 0x0000564b214503c9 in do_qmp_dispatch_bh at
../qapi/qmp-dispatch.c:110
11 0x0000564b21451996 in aio_bh_poll at ../util/async.c:164
12 0x0000564b2146018e in aio_dispatch at ../util/aio-posix.c:381
13 0x0000564b2145187e in aio_ctx_dispatch at ../util/async.c:306
14 0x00007f9040239049 in g_main_context_dispatch at
/lib/../lib64/libglib-2.0.so.0
15 0x0000564b21447368 in main_loop_wait at ../util/main-loop.c:232
16 0x0000564b21447368 in main_loop_wait at ../util/main-loop.c:255
17 0x0000564b21447368 in main_loop_wait at ../util/main-loop.c:531
18 0x0000564b212304e1 in qemu_main_loop at ../softmmu/runstate.c:721
19 0x0000564b20f7975e in main at ../softmmu/main.c:50

In IO thread when do bdrv_mirror_top_pwritev, the job is NULL, and stop field
is false, this means the MirrorBDSOpaque "s" object has not been initialized
yet, and this object is initialized by block_job_create(), but the initialize
process is stuck in acquiring the lock.

In this situation, IO thread come to bdrv_mirror_top_pwritev(),which means that
mirror-top node is already inserted into block graph, but its bs->opaque->job
is not initialized.

The root cause is that qemu main thread do release/acquire when hold the lock,
at the same time, IO thread get the lock after release stage, and the crash
occured.

Actually, in this situation, job->job.aio_context will not equal to
qemu_get_aio_context(), and will be the same as bs->aio_context,
thus, no need to release the lock, becasue bdrv_root_attach_child()
will not change the context.

This patch fix this issue.

Fixes: 132ada80 "block: Adjust AioContexts when attaching nodes"
Signed-off-by: Michael Qiu <qiudayu@huayun.com>
Message-Id: <20210203024059.52683-1-08005325@163.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

vhost-user-gpu: abstract vg_cleanup_mapping_iov

Git-commit: 3ea32d1355d446057c17458238db2749c52ee8f0
References: CVE-2021-3546 bsc#1185981
            CVE-2021-3545 bsc#1185990
            CVE-2021-3544

Currently in vhost-user-gpu, we free resource directly in
the cleanup case of resource. If we change the cleanup logic
we need to change several places, also abstruct a
'vg_create_mapping_iov' can be symmetry with the
'vg_create_mapping_iov'. This is like what virtio-gpu does,
no function changed.

Signed-off-by: Li Qiang <liq3ea@163.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20210516030403.107723-9-liq3ea@163.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Jose R. Ziviani <jziviani@suse.de>

vhost-user-gpu: fix OOB write in 'virgl_cmd_get_capset' (CVE-2021-3546)

Git-commit: 9f22893adcb02580aee5968f32baa2cd109b3ec2
References: CVE-2021-3546 bsc#1185981

If 'virgl_cmd_get_capset' set 'max_size' to 0,
the 'virgl_renderer_fill_caps' will write the data after the 'resp'.
This patch avoid this by checking the returned 'max_size'.

virtio-gpu fix: abd7f08b23 ("display: virtio-gpu-3d: check
virgl capabilities max_size")

Fixes: CVE-2021-3546
Reported-by: Li Qiang <liq3ea@163.com>
Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Li Qiang <liq3ea@163.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20210516030403.107723-8-liq3ea@163.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Jose R. Ziviani <jziviani@suse.de>

vhost-user-gpu: fix leak in 'virgl_resource_attach_backing' (CVE-2021-3544)

Git-commit: 63736af5a6571d9def93769431e0d7e38c6677bf
References: CVE-2021-3544

If 'virgl_renderer_resource_attach_iov' failed, the 'res_iovs' will
be leaked.

Fixes: CVE-2021-3544
Reported-by: Li Qiang <liq3ea@163.com>
virtio-gpu fix: 33243031da ("virtio-gpu-3d: fix memory leak
in resource attach backing")

Signed-off-by: Li Qiang <liq3ea@163.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20210516030403.107723-7-liq3ea@163.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Jose R. Ziviani <jziviani@suse.de>
[jrz: tweak title to not break spec file]

vhost-user-gpu: fix leak in 'virgl_cmd_resource_unref' (CVE-2021-3544)

Git-comit: f6091d86ba9ea05f4e111b9b42ee0005c37a6779
References: CVE-2021-3544

The 'res->iov' will be leaked if the guest trigger following sequences:

virgl_cmd_create_resource_2d
virgl_resource_attach_backing
virgl_cmd_resource_unref

This patch fixes this.

Fixes: CVE-2021-3544
Reported-by: Li Qiang <liq3ea@163.com>
virtio-gpu fix: 5e8e3c4c75 ("virtio-gpu: fix resource leak
in virgl_cmd_resource_unref"

Signed-off-by: Li Qiang <liq3ea@163.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20210516030403.107723-6-liq3ea@163.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Jose R. Ziviani <jziviani@suse.de>
[jrz: tweaked title to not break spec file]

vhost-user-gpu: fix memory leak while calling 'vg_resource_unref' (CVE-2021-3544)

Git-commit: b7afebcf9e6ecf3cf9b5a9b9b731ed04bca6aa3e
References: CVE-2021-3544

If the guest trigger following sequences, the attach_backing will be leaked:

vg_resource_create_2d
vg_resource_attach_backing
vg_resource_unref

This patch fix this by freeing 'res->iov' in vg_resource_destroy.

Fixes: CVE-2021-3544
Reported-by: Li Qiang <liq3ea@163.com>
virtio-gpu fix: 5e8e3c4c75 ("virtio-gpu: fix resource leak
in virgl_cmd_resource_unref")

Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Li Qiang <liq3ea@163.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20210516030403.107723-5-liq3ea@163.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Jose R. Ziviani <jziviani@suse.de>

vhost-user-gpu: fix memory leak in vg_resource_attach_backing (CVE-2021-3544)

Git-commit: b9f79858a614d95f5de875d0ca31096eaab72c3b
References: CVE-2021-3544

Check whether the 'res' has already been attach_backing to avoid
memory leak.

Fixes: CVE-2021-3544
Reported-by: Li Qiang <liq3ea@163.com>
virtio-gpu fix: 204f01b309 ("virtio-gpu: fix memory leak
in resource attach backing")

Signed-off-by: Li Qiang <liq3ea@163.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20210516030403.107723-4-liq3ea@163.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Jose R. Ziviani <jziviani@suse.de>

vhost-user-gpu: fix resource leak in 'vg_resource_create_2d' (CVE-2021-3544)

Git-commit: 86dd8fac2acc366930a5dc08d3fb1b1e816f4e1e
References: CVE-2021-3544

Call 'vugbm_buffer_destroy' in error path to avoid resource leak.

Fixes: CVE-2021-3544
Reported-by: Li Qiang <liq3ea@163.com>
Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Li Qiang <liq3ea@163.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20210516030403.107723-3-liq3ea@163.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Jose R. Ziviani <jziviani@suse.de>

vhost-user-gpu: fix memory disclosure in virgl_cmd_get_capset_info (CVE-2021-3545)

Git-commit: 121841b25d72d13f8cad554363138c360f1250ea
References: CVE-2021-3545 bsc#1185990

Otherwise some of the 'resp' will be leaked to guest.

Fixes: CVE-2021-3545
Reported-by: Li Qiang <liq3ea@163.com>
virtio-gpu fix: 42a8dadc74 ("virtio-gpu: fix information leak
in getting capset info dispatch")

Signed-off-by: Li Qiang <liq3ea@163.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20210516030403.107723-2-liq3ea@163.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Jose R. Ziviani <jziviani@suse.de>

migration/migration.c: Fix hang in ram_save_host_page

Git-commit: 773861274ad75a62c7ecf70ecc8e4ba31ed62190
References: bsc#1185591

migration_rate_limit will erroneously ratelimit a shutdown socket,
which causes the migration thread to hang in ram_save_host_page
if the socket is shutdown.

Fix this by explicitly testing if the socket has errors or was
shutdown in migration_rate_limit.

Signed-off-by: Lukas Straub <lukasstraub2@web.de>
Message-Id: <e79085bbe2d46dfa007dd41820194d5e2d4fcd80.1590007004.git.lukasstraub2@web.de>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
(cherry picked from commit 773861274ad75a62c7ecf70ecc8e4ba31ed62190)
Signed-off-by: Lin Ma <lma@suse.com>

xen-block: Fix removal of backend instance via xenstore

Git-commit: b807ca3fa0ca29ec015adcf4045e716337cd3635
References: bsc#1184574

Whenever a Xen block device is detach via xenstore, the image
associated with it remained open by the backend QEMU and an error is
logged:
    qemu-system-i386: failed to destroy drive: Node xvdz-qcow2 is in use

This happened since object_unparent() doesn't immediately frees the
object and thus keep a reference to the node we are trying to free.
The reference is hold by the "drive" property and the call
xen_block_drive_destroy() fails.

In order to fix that, we call drain_call_rcu() to run the callback
setup by bus_remove_child() via object_unparent().

Fixes: 2d24a6466154 ("device-core: use RCU for list of children of a bus")
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Paul Durrant <paul@xen.org>
Message-Id: <20210308143232.83388-1-anthony.perard@citrix.com>
Signed-off-by: Lin Ma <lma@suse.com>

scsi/scsi_bus: fix races in REPORT LUNS

Git-commit: 8cfe8013baec2a6f66240ffd767fad2699d85144
References: bsc#1184574

Currently scsi_target_emulate_report_luns iterates over the child device list
twice, and there is no guarantee that this list is the same in both iterations.

The reason for iterating twice is that the first iteration calculates
how much memory to allocate.  However if we use a dynamic array we can
avoid iterating twice, and therefore we avoid this race.

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1866707
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20200913160259.32145-10-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20201006123904.610658-14-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

virtio-scsi: use scsi_device_get

Git-commit: 07a47d4a1879370009baab44f1f387610d88a299
References: bsc#1184574

This will help us to avoid the scsi device disappearing
after we took a reference to it.

It doesn't by itself forbid case when we try to access
an unrealized device

Suggested-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20200913160259.32145-9-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20201006123904.610658-13-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

scsi/scsi_bus: Add scsi_device_get

Git-commit: 8ff34495601067d02edb54b4346cace84ec4e1df
References: bsc#1184574

Add scsi_device_get which finds the scsi device
and takes a reference to it.

Suggested-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20200913160259.32145-8-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20201006123904.610658-12-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

scsi/scsi-bus: scsi_device_find: don't return unrealized devices

Git-commit: 8ddf958e8d62ada6395460b91ec5964ef21fed12
References: bsc#1184574

The device core first places a device on the bus and then realizes it.
Make scsi_device_find avoid returing such devices to avoid
races in drivers that use an iothread (currently virtio-scsi)

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1812399

Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20200913160259.32145-7-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20201006123904.610658-11-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

device-core: use atomic_set on .realized property

Git-commit: a23151e8cc8cc08546252dc9c7671171d9c44615
References: bsc#1184574

Some code might race with placement of new devices on a bus.
We currently first place a (unrealized) device on the bus
and then realize it.

As a workaround, users that scan the child device list, can
check the realized property to see if it is safe to access such a device.
Use an atomic write here too to aid with this.

A separate discussion is what to do with devices that are unrealized:
It looks like for this case we only call the hotplug handler's unplug
callback and its up to it to unrealize the device.
An atomic operation doesn't cause harm for this code path though.

Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20200913160259.32145-6-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20201006123904.610658-10-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

scsi: switch to bus->check_address

Git-commit: 42a90a899e70f5fbef2b5a117535acaa0bc1f5ad
References: bsc#1184574

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20201006123904.610658-6-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

device-core: use RCU for list of children of a bus

Git-commit: 2d24a64661549732fc77f632928318dd52f5bce5
References: bsc#1184574

This fixes the race between device emulation code that tries to find
a child device to dispatch the request to (e.g a scsi disk),
and hotplug of a new device to that bus.

Note that this doesn't convert all the readers of the list
but only these that might go over that list without BQL held.

This is a very small first step to make this code thread safe.

Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20200913160259.32145-5-mlevitsk@redhat.com>
[Use RCU_READ_LOCK_GUARD in more places, adjust testcase now that
 the delay in DEVICE_DELETED due to RCU is more consistent. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20201006123904.610658-9-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

device_core: use drain_call_rcu in in qmp_device_add

Git-commit: 7bed89958bfbf40df9ca681cefbdca63abdde39d
References: bsc#1184574

Soon, a device removal might only happen on RCU callback execution.
This is okay for device-del which provides a DEVICE_DELETED event,
but not for the failure case of device-add.  To avoid changing
monitor semantics, just drain all pending RCU callbacks on error.

Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Suggested-by: Stefan Hajnoczi <stefanha@gmail.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20200913160259.32145-4-mlevitsk@redhat.com>
[Don't use it in qmp_device_del. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

scsi/scsi_bus: switch search direction in scsi_device_find

Git-commit: 7a8202c521a5d1ac9e289d5c2b5125a9310af178
References: bsc#1184574

This change will allow us to convert the bus children list to RCU,
while not changing the logic of this function

Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20200913160259.32145-2-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

qdev: add "check if address free" callback for buses

Git-commit: bb755ba47f3747251c0eadf681ee68b9033309b8
References: bsc#1184574

Check if an address is free on the bus before plugging in the
device.  This makes it possible to do the check without any
side effects, and to detect the problem early without having
to do it in the realize callback.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20201006123904.610658-5-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

rcu: Implement drain_call_rcu

Git-commit: d816614ca4f5af89a2b6d50ac840d7b77973f2fc
References: bsc#1184574

This will allow is to preserve the semantics of hmp_device_del,
that the device is deleted immediatly which was changed by previos
patch that delayed this to RCU callback

Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Suggested-by: Stefan Hajnoczi <stefanha@gmail.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20200915121318.247-2-luoyonggang@gmail.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

qom: make object_ref/unref use a void * instead of Object *.

Git-commit: c5a61e5a3c68144a421117916aef04f2c0fab84b
References: bsc#1184574

The object_ref/unref methods are intended for use with any subclass of
the base Object. Using "Object *" in the signature is not adding any
meaningful level of type safety, since callers simply use "OBJECT(ptr)"
and this expands to an unchecked cast "(Object *)".

By using "void *" we enable the object_unref() method to be used to
provide support for g_autoptr() with any subclass.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20200723181410.3145233-2-berrange@redhat.com>
Message-Id: <20200831210740.126168-2-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>

hw/sd/sdhci: Fix DMA Transfer Block Size field

Git-commit: dfba99f17feb6d4a129da19d38df1bcd8579d1c3
References: bsc#1176681 CVE-2020-25085

The 'Transfer Block Size' field is 12-bit wide.

See section '2.2.2. Block Size Register (Offset 004h)' in datasheet.

Two different bug reproducer available:
- https://bugs.launchpad.net/qemu/+bug/1892960
- https://ruhr-uni-bochum.sciebo.de/s/NNWP2GfwzYKeKwE?path=%2Fsdhci_oob_write1

Cc: qemu-stable@nongnu.org
Buglink: https://bugs.launchpad.net/qemu/+bug/1892960
Fixes: d7dfca0807a ("hw/sdhci: introduce standard SD host controller")
Reported-by: Alexander Bulekov <alxndr@bu.edu>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org>
Tested-by: Alexander Bulekov <alxndr@bu.edu>
Message-Id: <20200901140411.112150-3-f4bug@amsat.org>
Signed-off-by: Jose R Ziviani <jose.ziviani@suse.com>

pc-bios/s390-ccw: don't try to read the next block if end of chunk is reached

Git-commit: a6625d38cce3901a7c1cba069f0abcf743a293f1
References: bsc#1186290

Don't read the block if a null block number is reached, because this means that
the end of chunk is reached.

Reviewed-by: Collin Walling <walling@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Message-Id: <20210416074736.17409-1-mhartmay@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Cho, Yu-Chen <acho@suse.com>

virtio-scsi: change DID TIMEOUT handling

This patch implements a change of SG_ERR_DID_TIME_OUT handling as
suggested in
https://bugzilla.suse.com/show_bug.cgi?id=1178049#c145

Suggested-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Bruce Rogers <brogers@suse.com>

scsi-disk: trace rw errors

References: bsc#1178049

Add a tracepoints for R/W errors.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Bruce Rogers <brogers@suse.com>

scsi-disk: fold SG_IO errors back into request status

References: bsc#1178049

When SG_IO returns with a non-zero 'host_status' or 'status' we
should be folding these values into the request status to allow
any drivers to signal them back to the guest.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Bruce Rogers <brogers@suse.com>

scsi-generic: check for additional SG_IO status on completion

References: bsc#1178049

SG_IO may return additional status in the 'status', 'driver_status',
and 'host_status' fields. When either of these fields are set the
command has not been executed normally, so we should not continue
processing this command but rather return an error.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Bruce Rogers <brogers@suse.com>

virtio-scsi: translate SG_IO host status

References: bsc#1178049

when running with an SG_IO backend we might be getting a SCSI host
status back, which should be translated into a virtio scsi status
to avoid having a silent data corruption if the status isn't
translated properly.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Bruce Rogers <brogers@suse.com>

scsi-disk: set default I/O timeout to 30 seconds

References: bsc#1178049

To align with standard linux settings we should be setting the
default I/O timeout to 30 seconds, and add a lower bound of
5 seconds to avoid spurious I/O failures.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Bruce Rogers <brogers@suse.com>

scsi: add tracing for SG_IO commands

References: bsc#1178049

Add tracepoints for SG_IO commands to get a grip on the timeout
settings.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Bruce Rogers <brogers@suse.com>

scsi: make io_timeout settable

References: bsc#1178049

Add an 'io_timeout' parameter for SCSIDevice to allow
SG_IO ioctls to pass in a timeout, avoiding infinite
guest stalls if the host needs to abort a command.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Bruce Rogers <brogers@suse.com>

Revert meson build file back to Make.objs

References: bsc#1179719

Related commits: cd7498d07fbb 77280d33bc9c

Signed-off-by: Liang Yan <lyan@suse.com>