os-posix.c | 2 2 + 0 - 0 !
vl.c | 7 1 + 6 - 0 !
2 files changed, 3 insertions(+), 6 deletions(-)

 use fixed data dir instead of determining it at runtime

configure | 1 0 + 1 - 0 !
1 file changed, 1 deletion(-)

---

hw/usb/dev-mtp.c | 13 9 + 4 - 0 !
1 file changed, 9 insertions(+), 4 deletions(-)

 usb-mtp: use o_nofollow and o_cloexec.
Bug-Debian: https://bugs.debian.org/916397
Closes: #916397

Open files and directories with O_NOFOLLOW to avoid symlinks attacks.
While being at it also add O_CLOEXEC.

usb-mtp only handles regular files and directories and ignores

bt-host.c | 8 4 + 4 - 0 !
bt-vhci.c | 7 4 + 3 - 0 !
hw/bt/core.c | 2 1 + 1 - 0 !
hw/bt/hci-csr.c | 32 16 + 16 - 0 !
hw/bt/hci.c | 38 19 + 19 - 0 !
hw/bt/hid.c | 10 5 + 5 - 0 !
hw/bt/l2cap.c | 56 29 + 27 - 0 !
hw/bt/sdp.c | 6 3 + 3 - 0 !
hw/usb/dev-bluetooth.c | 12 6 + 6 - 0 !
include/hw/bt.h | 8 4 + 4 - 0 !
include/sysemu/bt.h | 10 5 + 5 - 0 !
11 files changed, 96 insertions(+), 93 deletions(-)

 bt: use size_t type for length parameters instead of int
Bug-Debian: https://bugs.debian.org/916278
Closes: #916278, CVE-2018-19665

The length parameter values are not negative, thus use an unsigned
type 'size_t' for them. Many routines pass 'len' values to memcpy(3)
calls. If it was negative, it could lead to memory corruption issues.
Add check to avoid it.

Reported-by: Arash TC <tohidi.arash@gmail.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>

hw/usb/ccid-card-emulated.c | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

 hw/usb: fix mistaken de-initialization of ccid state
Date: Fri, 21 Dec 2018 13:41:15 +0000
Message-Id: <20181221134115.27973-1-berrange@redhat.com>
Bug-Debian: https://bugs.debian.org/917007

In previous commit:

  commit 7dea29e4af17fc1d27478de9f8ea38144deac54a

linux-user/syscall_defs.h | 4 4 + 0 - 0 !
1 file changed, 4 insertions(+)

 sparc64 timeval.tv_usec is int


On sparc (only) Linux defines timeval::tv_usec with type int, not
long.  However qemu-user's definition of struct target_timeval uses
abi_long unconditionally.  This results in the syscall translation
layer effectively multiplying tv_usec by 2**32.  All sparc syscalls
passing non-zero values for this field fail with -EINVAL.

Laurent Vivier <laurent@vivier.eu>:

According to the kernel definition, I think it should be:

See arch/sparc/include/uapi/asm/posix_types.h

typedef int                    __kernel_suseconds_t;
..

linux-user/elfload.c | 5 5 + 0 - 0 !
1 file changed, 5 insertions(+)

 linux-user: sanitize interp_info and, for mips only, init field fp_abi
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Commit-Id: abcac736c1505254ec3f9587aff04fbe4705a55e
Bug-Debian: http://bugs.debian.org/933650

Sanitize interp_info structure in load_elf_binary() and, for MIPS only,
init its field fp_abi to MIPS_ABI_FP_UNKNOWN. This fixes appearances of
"Unexpected FPU mode" message in some MIPS use cases. Currently, this
bug is a complete stopper for some MIPS binaries.

In load_elf_binary(), struct image_info interp_info is used without
being properly initialized. One result is that when the ELF's program
header doesn't contain an entry for the ABI flags, then the value of
the struct image_info's fp_abi field is set to whatever happened to
be in stack memory at the time.

Backporting to 4.0 and, if possible, to 3.1 is recommended.

Fixes: https://bugs.launchpad.net/qemu/+bug/1825002

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com>

hw/scsi/scsi-generic.c | 18 10 + 8 - 0 !
1 file changed, 10 insertions(+), 8 deletions(-)

 scsi-generic: avoid possible out-of-bounds access to r->buf (cve-2019-6501)
Bug-Debian: http://bugs.debian.org/920222

Whenever the allocation length of a SCSI request is shorter than the size of the
VPD page list, page_idx is used blindly to index into r->buf.  Even though
the stores in the insertion sort are protected against overflows, the same is not
true of the reads and the final store of 0xb0.

This basically does the same thing as commit 57dbb58d80 ("scsi-generic: avoid
out-of-bounds access to VPD page list", 2018-11-06), except that here the
allocation length can be chosen by the guest.  Note that according to the SCSI
standard, the contents of the PAGE LENGTH field are not altered based
on the allocation length.

The code was introduced by commit 6c219fc8a1 ("scsi-generic: keep VPD
page list sorted", 2018-11-06) but the overflow was already possible before.

Reported-by: Kevin Wolf <kwolf@redhat.com>
Fixes: a71c775b24ebc664129eb1d9b4c360590353efd5
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

slirp/tcp_subr.c | 5 5 + 0 - 0 !
1 file changed, 5 insertions(+)

 slirp: check data length while emulating ident function (cve-2019-6778)
Bug-Debian: http://bugs.debian.org/921525

While emulating identification protocol, tcp_emu() does not check
available space in the 'sc_rcv->sb_data' buffer. It could lead to
heap buffer overflow issue. Add check to avoid it.

Reported-by: Kira <864786842@qq.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

hw/i2c/i2c-ddc.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 i2c-ddc: fix oob read
Commit-Id: b05b267840515730dbf6753495d5b7bd8b04ad1c
Bug-Debian: https://bugs.debian.org/922635
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Suggested-by: Michael Hanselmann <public@hansmi.ch>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

slirp/tcp_subr.c | 10 5 + 5 - 0 !
1 file changed, 5 insertions(+), 5 deletions(-)

 slirp: check sscanf result when emulating ident (cve-2019-9824)

device_tree.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 device_tree.c: don't use load_image() (cve-2018-20815)
Commit-Id: da885fe1ee8b4589047484bd7fa05a4905b52b17

The load_image() function is deprecated, as it does not let the
caller specify how large the buffer to read the file into is.
Instead use load_image_size().

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

hw/sparc64/sun4u.c | 6 6 + 0 - 0 !
1 file changed, 6 insertions(+)

 sun4u: add power_mem_read routine
Commit-Id: ad280559c68360c9f1cd7be063857853759e6a73
Bug-Debian: http://bugs.debian.org/927439

Define skeleton 'power_mem_read' routine. Avoid NULL dereference.

Reported-by: Fakhri Zulkifli <mohdfakhrizulkifli@gmail.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>

target/arm/helper.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 target/arm: allow aarch32 exception return to switch from mon->hyp
Commit-Id: 2d2a4549cc29850aab891495685a7b31f5254b12
Bug-Debian: http://bugs.debian.org/927763

In U-boot, we switch from S-SVC -> Mon -> Hyp mode when we want to
enter Hyp mode. The change into Hyp mode is done by doing an
exception return from Mon. This doesn't work with current QEMU.

The problem is that in bad_mode_switch() we refuse to allow
the change of mode.

Note that bad_mode_switch() is used to do validation for two situations:

 (1) changes to mode by instructions writing to CPSR.M
     (ie not exception take/return) -- this corresponds to the
     Armv8 Arm ARM pseudocode Arch32.WriteModeByInstr
 (2) changes to mode by exception return

Attempting to enter or leave Hyp mode via case (1) is forbidden in
v8 and UNPREDICTABLE in v7, and QEMU is correct to disallow it
there. However, we're already doing that check at the top of the
bad_mode_switch() function, so if that passes then we should allow
the case (2) exception return mode changes to switch into Hyp mode.

We want to test whether we're trying to return to the nonexistent
"secure Hyp" mode, so we need to look at arm_is_secure_below_el3()
rather than arm_is_secure(), since the latter is always true if
we're in Mon (EL3).

Signed-off-by: Alexander Graf <agraf@suse.de>

target/i386/cpu.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 target/i386: add mds-no feature
Bug-Debian: http://bugs.debian.org/929067

Microarchitectural Data Sampling is a hardware vulnerability which allows
unprivileged speculative access to data which is available in various CPU
internal buffers.

Some Intel processors use the ARCH_CAP_MDS_NO bit in the IA32_ARCH_CAPABILITIES
MSR to report that they are not vulnerable, make it available to guests.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
--
CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091

target/i386/cpu.c | 2 1 + 1 - 0 !
target/i386/cpu.h | 1 1 + 0 - 0 !
target/i386/hvf/x86_cpuid.c | 3 2 + 1 - 0 !
3 files changed, 4 insertions(+), 2 deletions(-)

 target/i386: define md-clear bit
Bug-Debian: http://bugs.debian.org/929067

md-clear is a new CPUID bit which is set when microcode provides the
mechanism to invoke a flush of various exploitable CPU buffers by invoking
the VERW instruction.  Add the new feature, and pass it down to
Hypervisor.framework guests.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

[Backported to qemu 3.1 - sbeattie]

target/i386/cpu.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 target/i386: add pschange_mc_no feature

This is required to disable ITLB multihit mitigations in nested
hypervisors.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

hw/display/qxl.c | 3 3 + 0 - 0 !
1 file changed, 3 insertions(+)

 qxl: check release info object (cve-2019-12155)
Bug-Debian: http://bugs.debian.org/929353

When releasing spice resources in release_resource() routine,
if release info object 'ext.info' is null, it leads to null
pointer dereference. Add check to avoid it.

Reported-by: Bugs SysSec <bugs-syssec@rub.de>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Message-id: 20190425063534.32747-1-ppandit@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

qemu-bridge-helper.c | 11 11 + 0 - 0 !
1 file changed, 11 insertions(+)

 qemu-bridge-helper: restrict interface name to ifnamsiz
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Commit-Id: 6f5d8671225dc77190647f18a27a0d156d4ca97a
Bug-Debian: https://bugs.debian.org/931351

The network interface name in Linux is defined to be of size
IFNAMSIZ(=16), including the terminating null('\0') byte.
The same is applied to interface names read from 'bridge.conf'
file to form ACL rules. If user supplied '--br=bridge' name
is not restricted to the same length, it could lead to ACL bypass
issue. Restrict interface name to IFNAMSIZ, including null byte.

Reported-by: Riccardo Schirone <rschiron@redhat.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>

slirp/ip_input.c | 4 3 + 1 - 0 !
1 file changed, 3 insertions(+), 1 deletion(-)

 fix heap overflow in ip_reass on big packet input
Commit-Id: 126c04acbabd7ad32c2b018fe10dfac2a3bc1210
Bug-Debian: http://bugs.debian.org/933741

When the first fragment does not fit in the preallocated buffer, q will
already be pointing to the ext buffer, so we mustn't try to update it.

Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

slirp/ip_input.c | 6 4 + 2 - 0 !
1 file changed, 4 insertions(+), 2 deletions(-)

 ip_reass: fix use after free (cve-2019-15890)
Commit-Id: c59279437eda91841b9d26079c70b8a540d41204
Bug-Debian: http://bugs.debian.org/939869

Using ip_deq after m_free might read pointers from an allocation reuse.

slirp/ip_input.c | 6 2 + 4 - 0 !
1 file changed, 2 insertions(+), 4 deletions(-)

 fix use-afte-free in ip_reass() (cve-2020-1983)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The q pointer is updated when the mbuf data is moved from m_dat to
m_ext.

m_ext buffer may also be realloc()'ed and moved during m_cat():
q should also be updated in this case.

Reported-by: Aviv Sasson <asasson@paloaltonetworks.com>
Signed-off-by: Marc-Andr Lureau <marcandre.lureau@redhat.com>

slirp/tcp_subr.c | 7 7 + 0 - 0 !
1 file changed, 7 insertions(+)

 tcp_emu: fix oob access
Bug-Debian: http://bugs.debian.org/949084

The main loop only checks for one available byte, while we sometimes
need two bytes.

slirp/tcp_subr.c | 8 4 + 4 - 0 !
1 file changed, 4 insertions(+), 4 deletions(-)

 slirp: use correct size while emulating commands
Bug-Debian: http://bugs.debian.org/949084

While emulating services in tcp_emu(), it uses 'mbuf' size
'm->m_size' to write commands via snprintf(3). Use M_FREEROOM(m)
size to avoid possible OOB access.

Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Message-Id: <20200109094228.79764-3-ppandit@redhat.com>

slirp/tcp_subr.c | 6 3 + 3 - 0 !
1 file changed, 3 insertions(+), 3 deletions(-)

 slirp: use correct size while emulating irc commands
Bug-Debian: http://bugs.debian.org/949084

While emulating IRC DCC commands, tcp_emu() uses 'mbuf' size
'm->m_size' to write DCC commands via snprintf(3). This may
lead to OOB write access, because 'bptr' points somewhere in
the middle of 'mbuf' buffer, not at the start. Use M_FREEROOM(m)
size to avoid OOB access.

Reported-by: Vishnu Dev TJ <vishnudevtj@gmail.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>

slirp/ip6_input.c | 7 7 + 0 - 0 !
1 file changed, 7 insertions(+)

 drop bogus ipv6 messages

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().

slirp/main.h | 3 3 + 0 - 0 !
slirp/slirp.c | 62 62 + 0 - 0 !
2 files changed, 65 insertions(+)

 [patch] util: add slirp_fmt() helpers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Various calls to snprintf() in libslirp assume that snprintf() returns
"only" the number of bytes written (excluding terminating NUL).

https://pubs.opengroup.org/onlinepubs/9699919799/functions/snprintf.html#tag_16_159_04

"Upon successful completion, the snprintf() function shall return the
number of bytes that would be written to s had n been sufficiently
large excluding the terminating null byte."

Introduce slirp_fmt() that handles several pathological cases the
way libslirp usually expect:

- treat error as fatal (instead of silently returning -1)

- fmt0() will always \0 end

- return the number of bytes actually written (instead of what would
have been written, which would usually result in OOB later), including
the ending \0 for fmt0()

- warn if truncation happened (instead of ignoring)

Other less common cases can still be handled with strcpy/snprintf() etc.

Signed-off-by: Marc-Andr Lureau <marcandre.lureau@redhat.com>

slirp/tcp_subr.c | 40 20 + 20 - 0 !
1 file changed, 20 insertions(+), 20 deletions(-)

 [patch] tcp_emu: fix unsafe snprintf() usages
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Various calls to snprintf() assume that snprintf() returns "only" the
number of bytes written (excluding terminating NUL).

https://pubs.opengroup.org/onlinepubs/9699919799/functions/snprintf.html#tag_16_159_04

"Upon successful completion, the snprintf() function shall return the
number of bytes that would be written to s had n been sufficiently
large excluding the terminating null byte."

Before patch ce131029, if there isn't enough room in "m_data" for the
"DCC ..." message, we overflow "m_data".

After the patch, if there isn't enough room for the same, we don't
overflow "m_data", but we set "m_len" out-of-bounds. The next time an
access is bounded by "m_len", we'll have a buffer overflow then.

Use slirp_fmt*() to fix potential OOB memory access.

Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Marc-Andr Lureau <marcandre.lureau@redhat.com>

io/channel-socket.c | 19 4 + 15 - 0 !
1 file changed, 4 insertions(+), 15 deletions(-)

 io: ensure unix client doesn't unlink server socket
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Bug-Debian: http://bugs.debian.org/946210

The qio_channel_socket_close method for was mistakenly unlinking the
UNIX server socket, even if the channel was a client connection. This
was not noticed with chardevs, since they never call close, but with the
VNC server, this caused the VNC server socket to be deleted after the
first client quit.

The qio_channel_socket_close method also needlessly reimplemented the
logic that already exists in socket_listen_cleanup(). Just call that
method directly, for listen sockets only.

This fixes a regression introduced in QEMU 3.0.0 with

  commit d66f78e1eaa832f73c771d9df1b606fe75d52a50

block/iscsi.c | 5 3 + 2 - 0 !
1 file changed, 3 insertions(+), 2 deletions(-)

 iscsi: cap block count from get lba status (cve-2020-1711)
Commit-Id: 693fd2acdf14dd86c0bf852610f1c2cca80a74dc
Bug-Debian: http://bugs.debian.org/949731

When querying an iSCSI server for the provisioning status of blocks (via
GET LBA STATUS), Qemu only validates that the response descriptor zero's
LBA matches the one requested. Given the SCSI spec allows servers to
respond with the status of blocks beyond the end of the LUN, Qemu may
have its heap corrupted by clearing/setting too many bits at the end of
its allocmap for the LUN.

A malicious guest in control of the iSCSI server could carefully program
Qemu's heap (by selectively setting the bitmap) and then smash it.

This limits the number of bits that iscsi_co_block_status() will try to
update in the allocmap so it can't overflow the bitmap.

Fixes: CVE-2020-1711
Cc: qemu-stable@nongnu.org
Signed-off-by: Felipe Franciosi <felipe@nutanix.com>
Signed-off-by: Peter Turschmid <peter.turschm@nutanix.com>
Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>

hw/display/bochs-display.c | 7 6 + 1 - 0 !
1 file changed, 6 insertions(+), 1 deletion(-)

 display/bochs: fix pcie support

Set QEMU_PCI_CAP_EXPRESS unconditionally in init(), then clear it in
realize() in case the device is not connected to a PCIe bus.

This makes sure the pci config space allocation is big enough, so
accessing the PCIe extended config space doesn't overflow the pci
config space buffer.

PCI(e) config space is guest writable.  Writes are limited by
write mask (which probably is also filled with random stuff),
so the guest can only flip enabled bits.  But I suspect it
still might be exploitable, so rather serious because it might
be a host escape for the guest.  On the other hand the device
is probably not yet in widespread use.

(For a QEMU version without this commit, a mitigation for the
bug is available: use "-device bochs-display" as a conventional pci
device only.)

Cc: qemu-stable@nongnu.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 20190812065221.20907-2-kraxel@redhat.com

ui/vnc-enc-tight.c | 219 111 + 108 - 0 !
ui/vnc-enc-zlib.c | 11 6 + 5 - 0 !
ui/vnc-enc-zrle.c | 68 34 + 34 - 0 !
ui/vnc-enc-zrle.inc.c | 2 1 + 1 - 0 !
ui/vnc.c | 28 16 + 12 - 0 !
ui/vnc.h | 4 2 + 2 - 0 !
6 files changed, 170 insertions(+), 162 deletions(-)

 vnc: fix memory leak when vnc disconnect

Currently when qemu receives a vnc connect, it creates a 'VncState' to
represent this connection. In 'vnc_worker_thread_loop' it creates a
local 'VncState'. The connection 'VcnState' and local 'VncState' exchange
data in 'vnc_async_encoding_start' and 'vnc_async_encoding_end'.
In 'zrle_compress_data' it calls 'deflateInit2' to allocate the libz library
opaque data. The 'VncState' used in 'zrle_compress_data' is the local
'VncState'. In 'vnc_zrle_clear' it calls 'deflateEnd' to free the libz
library opaque data. The 'VncState' used in 'vnc_zrle_clear' is the connection
'VncState'. In currently implementation there will be a memory leak when the
vnc disconnect. Following is the asan output backtrack:

hw/scsi/lsi53c895a.c | 41 27 + 14 - 0 !
1 file changed, 27 insertions(+), 14 deletions(-)

 scsi: lsi: exit infinite loop while executing script (cve-2019-12068)

When executing script in lsi_execute_script(), the LSI scsi adapter
emulator advances 's->dsp' index to read next opcode. This can lead
to an infinite loop if the next opcode is empty. Move the existing
loop exit after 10k iterations so that it covers no-op opcodes as
well.

Reported-by: Bugs SysSec <bugs-syssec@rub.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

block/iscsi.c | 3 1 + 2 - 0 !
1 file changed, 1 insertion(+), 2 deletions(-)

 block/iscsi: fix heap-buffer-overflow in iscsi_aio_ioctl_cb
Date: Sat, 18 Apr 2020 14:26:02 +0800

There is an overflow, the source 'datain.data[2]' is 100 bytes,
 but the 'ss' is 252 bytes.This may cause a security issue because
 we can access a lot of unrelated memory data.

The len for sbp copy data should take the minimum of mx_sb_len and
 sb_len_wr, not the maximum.

If we use iscsi device for VM backend storage, ASAN show stack:

READ of size 252 at 0xfffd149dcfc4 thread T0
    #0 0xaaad433d0d34 in __asan_memcpy (aarch64-softmmu/qemu-system-aarch64+0x2cb0d34)
    #1 0xaaad45f9d6d0 in iscsi_aio_ioctl_cb /qemu/block/iscsi.c:996:9
    #2 0xfffd1af0e2dc  (/usr/lib64/iscsi/libiscsi.so.8+0xe2dc)
    #3 0xfffd1af0d174  (/usr/lib64/iscsi/libiscsi.so.8+0xd174)
    #4 0xfffd1af19fac  (/usr/lib64/iscsi/libiscsi.so.8+0x19fac)
    #5 0xaaad45f9acc8 in iscsi_process_read /qemu/block/iscsi.c:403:5
    #6 0xaaad4623733c in aio_dispatch_handler /qemu/util/aio-posix.c:467:9
    #7 0xaaad4622f350 in aio_dispatch_handlers /qemu/util/aio-posix.c:510:20
    #8 0xaaad4622f350 in aio_dispatch /qemu/util/aio-posix.c:520
    #9 0xaaad46215944 in aio_ctx_dispatch /qemu/util/async.c:298:5
    #10 0xfffd1bed12f4 in g_main_context_dispatch (/lib64/libglib-2.0.so.0+0x512f4)
    #11 0xaaad46227de0 in glib_pollfds_poll /qemu/util/main-loop.c:219:9
    #12 0xaaad46227de0 in os_host_main_loop_wait /qemu/util/main-loop.c:242
    #13 0xaaad46227de0 in main_loop_wait /qemu/util/main-loop.c:518
    #14 0xaaad43d9d60c in qemu_main_loop /qemu/softmmu/vl.c:1662:9
    #15 0xaaad4607a5b0 in main /qemu/softmmu/main.c:49:5
    #16 0xfffd1a460b9c in __libc_start_main (/lib64/libc.so.6+0x20b9c)
    #17 0xaaad43320740 in _start (aarch64-softmmu/qemu-system-aarch64+0x2c00740)

0xfffd149dcfc4 is located 0 bytes to the right of 100-byte region [0xfffd149dcf60,0xfffd149dcfc4)
allocated by thread T0 here:
    #0 0xaaad433d1e70 in __interceptor_malloc (aarch64-softmmu/qemu-system-aarch64+0x2cb1e70)
    #1 0xfffd1af0e254  (/usr/lib64/iscsi/libiscsi.so.8+0xe254)
    #2 0xfffd1af0d174  (/usr/lib64/iscsi/libiscsi.so.8+0xd174)
    #3 0xfffd1af19fac  (/usr/lib64/iscsi/libiscsi.so.8+0x19fac)
    #4 0xaaad45f9acc8 in iscsi_process_read /qemu/block/iscsi.c:403:5
    #5 0xaaad4623733c in aio_dispatch_handler /qemu/util/aio-posix.c:467:9
    #6 0xaaad4622f350 in aio_dispatch_handlers /qemu/util/aio-posix.c:510:20
    #7 0xaaad4622f350 in aio_dispatch /qemu/util/aio-posix.c:520
    #8 0xaaad46215944 in aio_ctx_dispatch /qemu/util/async.c:298:5
    #9 0xfffd1bed12f4 in g_main_context_dispatch (/lib64/libglib-2.0.so.0+0x512f4)
    #10 0xaaad46227de0 in glib_pollfds_poll /qemu/util/main-loop.c:219:9
    #11 0xaaad46227de0 in os_host_main_loop_wait /qemu/util/main-loop.c:242
    #12 0xaaad46227de0 in main_loop_wait /qemu/util/main-loop.c:518
    #13 0xaaad43d9d60c in qemu_main_loop /qemu/softmmu/vl.c:1662:9
    #14 0xaaad4607a5b0 in main /qemu/softmmu/main.c:49:5
    #15 0xfffd1a460b9c in __libc_start_main (/lib64/libc.so.6+0x20b9c)
    #16 0xaaad43320740 in _start (aarch64-softmmu/qemu-system-aarch64+0x2c00740)

Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>

hw/core/loader.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 hw/core/loader: fix possible crash in rom_copy()

Both, "rom->addr" and "addr" are derived from the binary image
that can be loaded with the "-kernel" paramer. The code in
rom_copy() then calculates:

    d = dest + (rom->addr - addr);

and uses "d" as destination in a memcpy() some lines later. Now with
bad kernel images, it is possible that rom->addr is smaller than addr,
thus "rom->addr - addr" gets negative and the memcpy() then tries to
copy contents from the image to a bad memory location. This could
maybe be used to inject code from a kernel image into the QEMU binary,
so we better fix it with an additional sanity check here.

Cc: qemu-stable@nongnu.org
Reported-by: Guangming Liu
Buglink: https://bugs.launchpad.net/qemu/+bug/1844635
Message-Id: <20190925130331.27825-1-thuth@redhat.com>

memory.c | 29 9 + 20 - 0 !
1 file changed, 9 insertions(+), 20 deletions(-)

 memory: revert "memory: accept mismatching sizes in
 memory_region_access_valid"

Memory API documentation documents valid .min_access_size and .max_access_size
fields and explains that any access outside these boundaries is blocked.

This is what devices seem to assume.

However this is not what the implementation does: it simply
ignores the boundaries unless there's an "accepts" callback.

Naturally, this breaks a bunch of devices.

Revert to the documented behaviour.

Devices that want to allow any access can just drop the valid field,
or add the impl field to have accesses converted to appropriate
length.

Cc: qemu-stable@nongnu.org

hw/acpi/core.c | 9 6 + 3 - 0 !
1 file changed, 6 insertions(+), 3 deletions(-)

 acpi: accept byte and word access to core acpi registers
Bug-Debian: https://bugs.debian.org/964793
Bug-Debian: https://bugs.debian.org/964247

All ISA registers should be accessible as bytes, words or dwords
(if wide enough).  Fix the access constraints for acpi-pm-evt,
acpi-pm-tmr & acpi-cnt registers.

Fixes: 5d971f9e67 (memory: Revert "memory: accept mismatching sizes in memory_region_access_valid")
Fixes: afafe4bbe0 (apci: switch cnt to memory api)
Fixes: 77d58b1e47 (apci: switch timer to memory api)
Fixes: b5a7c024d2 (apci: switch evt to memory api)
Buglink: https://lore.kernel.org/xen-devel/20200630170913.123646-1-anthony.perard@citrix.com/T/
Buglink: https://bugs.debian.org/964793
BugLink: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964247
BugLink: https://bugs.launchpad.net/bugs/1886318
Reported-By: Simon John <git@the-jedi.co.uk>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

hw/usb/hcd-xhci.c | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 xhci: fix valid.max_access_size to access address registers
Date: Tue, 21 Jul 2020 10:33:22 +0200
Message-Id: <20200721083322.90651-1-lvivier@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

QEMU XHCI advertises AC64 (64-bit addressing) but doesn't allow
64-bit mode access in "runtime" and "operational" MemoryRegionOps.

Set the max_access_size based on sizeof(dma_addr_t) as AC64 is set.

XHCI specs:
"If the xHC supports 64-bit addressing (AC64 = 1), then software
should write 64-bit registers using only Qword accesses.  If a
system is incapable of issuing Qword accesses, then writes to the
64-bit address fields shall be performed using 2 Dword accesses;
low Dword-first, high-Dword second.  If the xHC supports 32-bit
addressing (AC64 = 0), then the high Dword of registers containing
64-bit address fields are unused and software should write addresses
using only Dword accesses"

The problem has been detected with SLOF, as linux kernel always accesses
registers using 32-bit access even if AC64 is set and revealed by
5d971f9e6725 ("memory: Revert "memory: accept mismatching sizes in memory_region_access_valid"")

Suggested-by: Alexey Kardashevskiy <aik@au1.ibm.com>
Signed-off-by: Laurent Vivier <lvivier@redhat.com>

exec.c | 1 1 + 0 - 0 !
include/exec/memory.h | 3 2 + 1 - 0 !
2 files changed, 3 insertions(+), 1 deletion(-)

 exec: set map length to zero when returning null
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When mapping physical memory into host's virtual address space,
'address_space_map' may return NULL if BounceBuffer is in_use.
Set and return '*plen = 0' to avoid later NULL pointer dereference.

Reported-by: Alexander Bulekov <alxndr@bu.edu>
Fixes: https://bugs.launchpad.net/qemu/+bug/1878259
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Message-Id: <20200526111743.428367-1-ppandit@redhat.com>

hw/scsi/megasas.c | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 megasas: use unsigned type for reply_queue_head and check index
Bug-Debian: http://bugs.debian.org/961887

A guest user may set 'reply_queue_head' field of MegasasState to
a negative value. Later in 'megasas_lookup_frame' it is used to
index into s->frames[] array. Use unsigned type to avoid OOB
access issue.

Also check that 'index' value stays within s->frames[] bounds
through the while() loop in 'megasas_lookup_frame' to avoid OOB
access.

Reported-by: Ren Ding <rding@gatech.edu>
Reported-by: Hanqing Zhao <hanqing@gatech.edu>
Reported-by: Alexander Bulekov <alxndr@bu.edu>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>

hw/scsi/megasas.c | 38 19 + 19 - 0 !
1 file changed, 19 insertions(+), 19 deletions(-)

 megasas: use unsigned type for positive numeric fields
Bug-Debian: http://bugs.debian.org/961887

Use unsigned type for the MegasasState fields which hold positive
numeric values.

Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>

hw/scsi/megasas.c | 36 23 + 13 - 0 !
1 file changed, 23 insertions(+), 13 deletions(-)

 hw/scsi/megasas: fix possible out-of-bounds array access in tracepoints
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Some tracepoints in megasas.c use a guest-controlled value as an index
into the mfi_frame_desc[] array. Thus a malicious guest could cause an
out-of-bounds error here. Fortunately, the impact is very low since this
can only happen when the corresponding tracepoints have been enabled
before, but the problem should be fixed anyway with a proper check.

Buglink: https://bugs.launchpad.net/qemu/+bug/1882065
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20200615072629.32321-1-thuth@redhat.com>

hw/audio/es1370.c | 7 5 + 2 - 0 !
1 file changed, 5 insertions(+), 2 deletions(-)

 es1370: check total frame count against current frame

A guest user may set channel frame count via es1370_write()
such that, in es1370_transfer_audio(), total frame count
'size' is lesser than the number of frames that are processed
'cnt'.

    int cnt = d->frame_cnt >> 16;
    int size = d->frame_cnt & 0xffff;

if (size < cnt), it results in incorrect calculations leading
to OOB access issue(s). Add check to avoid it.

Reported-by: Ren Ding <rding@gatech.edu>
Reported-by: Hanqing Zhao <hanqing@gatech.edu>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Message-id: 20200514200608.1744203-1-ppandit@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

hw/net/xgmac.c | 14 12 + 2 - 0 !
1 file changed, 12 insertions(+), 2 deletions(-)

 hw/net/xgmac: fix buffer overflow in xgmac_enet_send()

A buffer overflow issue was reported by Mr. Ziming Zhang, CC'd here. It
occurs while sending an Ethernet frame due to missing break statements
and improper checking of the buffer size.

Reported-by: Ziming Zhang <ezrakiez@gmail.com>
Signed-off-by: Mauro Matteo Cascella <mcascell@redhat.com>

hw/display/sm501.c | 57 27 + 30 - 0 !
1 file changed, 27 insertions(+), 30 deletions(-)

 sm501: convert printf + abort to qemu_log_mask
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Some places already use qemu_log_mask() to log unimplemented features
or errors but some others have printf() then abort(). Convert these to
qemu_log_mask() and avoid aborting to prevent guests to easily cause
denial of service.

Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>

hw/display/sm501.c | 45 22 + 23 - 0 !
1 file changed, 22 insertions(+), 23 deletions(-)

 sm501: shorten long variable names in sm501_2d_operation

This increases readability and cleans up some confusing naming.

Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-id: b9b67b94c46e945252a73c77dfd117132c63c4fb.1590089984.git.balaton@eik.bme.hu
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

hw/display/sm501.c | 5 2 + 3 - 0 !
1 file changed, 2 insertions(+), 3 deletions(-)

 sm501: use bit(x) macro to shorten constant
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>

hw/display/sm501.c | 31 16 + 15 - 0 !
1 file changed, 16 insertions(+), 15 deletions(-)

 sm501: clean up local variables in sm501_2d_operation
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Make variables local to the block they are used in to make it clearer
which operation they are needed for.

Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>

hw/display/sm501.c | 207 119 + 88 - 0 !
1 file changed, 119 insertions(+), 88 deletions(-)

 sm501: replace hand written implementation with pixman where possible
Bug-Debian: https://bugs.debian.org/961451

Besides being faster this should also prevent malicious guests to
abuse 2D engine to overwrite data or cause a crash.

Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-id: 58666389b6cae256e4e972a32c05cf8aa51bffc0.1590089984.git.balaton@eik.bme.hu
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

hw/usb/core.c | 16 10 + 6 - 0 !
1 file changed, 10 insertions(+), 6 deletions(-)

 usb: fix setup_len init (cve-2020-14364)
Bug-Debian: https://bugs.debian.org/968947

Store calculated setup_len in a local variable, verify it, and only
write it to the struct (USBDevice->setup_len) in case it passed the
sanity checks.

This prevents other code (do_token_{in,out} functions specifically)
from working with invalid USBDevice->setup_len values and overrunning
the USBDevice->setup_buf[] buffer.

Fixes: CVE-2020-14364
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Gonglei <arei.gonglei@huawei.com>

hw/net/net_tx_pkt.c | 5 4 + 1 - 0 !
1 file changed, 4 insertions(+), 1 deletion(-)

 hw/net/net_tx_pkt: fix assertion failure in net_tx_pkt_add_raw_fragment()

An assertion failure issue was found in the code that processes network packets
while adding data fragments into the packet context. It could be abused by a
malicious guest to abort the QEMU process on the host. This patch replaces the
affected assert() with a conditional statement, returning false if the current
data fragment exceeds max_raw_frags.

Reported-by: Alexander Bulekov <alxndr@bu.edu>
Reported-by: Ziming Zhang <ezrakiez@gmail.com>