softmmu/vl.c | 2 2 + 0 - 0 !
util/cutils.c | 4 4 + 0 - 0 !
2 files changed, 6 insertions(+)

 use fixed data dir instead of determining it at runtime

hw/i386/microvm.c | 3 3 + 0 - 0 !
hw/i386/pc_piix.c | 5 5 + 0 - 0 !
2 files changed, 8 insertions(+)

 set default machine type to be microvm if config_microvm is defined
Debian-Specific: yes

meson.build | 14 10 + 4 - 0 !
1 file changed, 10 insertions(+), 4 deletions(-)

 build most modules statically (hack)

This hack makes the build procedure to build most modules statically,
except block and gui modules which goes into their own packages.
The rest are built into the executables directly in order to make
qemu-system-common package (where all other modules goes) to be
more-or-less version-independent.

There's little reason to build these as modules or to ship them in
separate packages.

meson.build | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 do not include pc-bios/meson.build from main build as we build all firmware separately

pc-bios/meson.build tries to link various firmware files to the build
directory, but we DFSG-removed them so the build fails to find them.
Just disable entering the subdir entirely since we buile all the
necessary firmware in d/rules anyway.

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

 [patch, hack]: linux-user: handle binfmt-misc p flag as a separate exe name

roms/openbios/drivers/usbohci.c | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

---

roms/openbios/Makefile.target | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 roms/openbios: use source_date_epoch in makefile.

Embedding the build time breaks reproducibility. Instead, use the date
specified by the SOURCE_DATE_EPOCH environment variable:

  https://reproducible-builds.org/docs/source-date-epoch/

This patch relies on features of GNU date, and will need further
changes for portability to other systems.

roms/seabios-hppa/scripts/buildversion.py | 5 2 + 3 - 0 !
1 file changed, 2 insertions(+), 3 deletions(-)

 roms/seabios-hppa: use consistent date and remove hostname.

Two issues break reproducibility; the time and hostname get embedded
in the resulting seabios binary.

Simply drop the hostname from the embedded version string, as it
shouldn't be needed in Debian package builds.

Use the SOURCE_DATE_EPOCH environment variable to set the build date
rather than the current time:

  https://reproducible-builds.org/docs/source-date-epoch/

roms/SLOF/Makefile.gen | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 roms/slof/makefile.gen: remove user and host from release version.

This version string ends up in the slof.bin, leading to
reproducibility issues.

roms/SLOF/Makefile.gen | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 slof/makefile.gen: ensure ld is called with the c locale.

The output of "ld -V" changes based on the environment's locale.

disas/nanomips.cpp | 2 1 + 1 - 0 !
hw/misc/trace-events | 2 1 + 1 - 0 !
hw/net/allwinner-sun8i-emac.c | 2 1 + 1 - 0 !
hw/ppc/pnv_bmc.c | 2 1 + 1 - 0 !
hw/usb/ccid-card-emulated.c | 2 1 + 1 - 0 !
hw/usb/hcd-ohci.c | 2 1 + 1 - 0 !
hw/virtio/vhost.c | 2 1 + 1 - 0 !
include/hw/s390x/css.h | 2 1 + 1 - 0 !
qemu-options.hx | 2 1 + 1 - 0 !
target/i386/cpu.c | 2 1 + 1 - 0 !
target/i386/machine.c | 2 1 + 1 - 0 !
target/m68k/op_helper.c | 2 1 + 1 - 0 !
target/riscv/cpu.c | 2 1 + 1 - 0 !
13 files changed, 13 insertions(+), 13 deletions(-)

 various spelling fixes

pc-bios/descriptors/meson.build | 3 1 + 2 - 0 !
1 file changed, 1 insertion(+), 2 deletions(-)

 pc-bios/descriptors: fix paths in json files
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Before the change /usr/share/qemu/firmware/50-edk2-x86_64-secure.json
contained the relative path:
            "filename": "share/qemu/edk2-x86_64-secure-code.fd",
            "filename": "share/qemu/edk2-i386-vars.fd",

After then change the paths are absolute:
            "filename": "/usr/share/qemu/edk2-x86_64-secure-code.fd",
            "filename": "/usr/share/qemu/edk2-i386-vars.fd",

The regression appeared in qemu-5.2.0 (seems to be related
to meson port).

CC: Paolo Bonzini <pbonzini@redhat.com>
CC: "Marc-André Lureau" <marcandre.lureau@redhat.com>
CC: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Bug: https://bugs.gentoo.org/766743
Bug: https://bugs.launchpad.net/qemu/+bug/1913012
Signed-off-by: Jannik Glückert <jannik.glueckert@gmail.com>
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Message-Id: <20210131143434.2513363-1-slyfox@gentoo.org>
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

softmmu/physmem.c | 10 10 + 0 - 0 !
tests/qtest/fuzz-test.c | 51 51 + 0 - 0 !
2 files changed, 61 insertions(+)

 memory: clamp cached translation in case it points to an mmio region
Bug-Debian: https://bugs.debian.org/977616
Bug: https://security-tracker.debian.org/tracker/CVE-2020-27821

In using the address_space_translate_internal API, address_space_cache_init
forgot one piece of advice that can be found in the code for
address_space_translate_internal:

    /* MMIO registers can be expected to perform full-width accesses based only
     * on their address, without considering adjacent registers that could

Makefile | 24 2 + 22 - 0 !
configure | 51 38 + 13 - 0 !
scripts/git-submodule.sh | 34 26 + 8 - 0 !
3 files changed, 66 insertions(+), 43 deletions(-)

 [patch] configure: replace --enable/disable-git-update with
 --with-git-submodules
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Replace the --enable-git-update and --disable-git-update configure params
with the param --with-git-submodules=(update|validate|ignore) to
allow 3 options for building from a git repo.

This is needed because downstream packagers, e.g. Debian, Ubuntu, etc,
also keep the source code in git, but do not want to enable the
'git_update' mode; with the current code, that's not possible even
if the downstream package specifies --disable-git-update.

The previous parameters are deprecated but still available; the
--enable-git-update parameter maps to --with-git-submodules=update and
--disable-git-update parameter maps to --with-git-submodules=validate.

The configure script behavior is slightly modified, where previously
the dtc, capstone, and slirp submodules were not validated when
--disable-git-update was specified (but were updated with git-update
enabled), now they are validated when using --with-git-submodules=validate
and are only ignored when using --with-git-submodules=ignore.

Signed-off-by: Dan Streetman <ddstreet@canonical.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

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

 hw/intc/arm_gic: fix interrupt id in gicd_sgir register
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Per the ARM Generic Interrupt Controller Architecture specification
(document "ARM IHI 0048B.b (ID072613)"), the SGIINTID field is 4 bit,
not 10:

  - 4.3 Distributor register descriptions
  - 4.3.15 Software Generated Interrupt Register, GICD_SG

    - Table 4-21 GICD_SGIR bit assignments

    The Interrupt ID of the SGI to forward to the specified CPU
    interfaces. The value of this field is the Interrupt ID, in
    the range 0-15, for example a value of 0b0011 specifies
    Interrupt ID 3.

Correct the irq mask to fix an undefined behavior (which eventually
lead to a heap-buffer-overflow, see [Buglink]):

   $ echo 'writel 0x8000f00 0xff4affb0' | qemu-system-aarch64 -M virt,accel=qtest -qtest stdio
   [I 1612088147.116987] OPENED
  [R +0.278293] writel 0x8000f00 0xff4affb0
  ../hw/intc/arm_gic.c:1498:13: runtime error: index 944 out of bounds for type 'uint8_t [16][8]'
  SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/intc/arm_gic.c:1498:13

This fixes a security issue when running with KVM on Arm with
kernel-irqchip=off. (The default is kernel-irqchip=on, which is
unaffected, and which is also the correct choice for performance.)

Cc: qemu-stable@nongnu.org
Fixes: CVE-2021-20221
Fixes: 9ee6e8bb853 ("ARMv7 support.")
Buglink: https://bugs.launchpad.net/qemu/+bug/1913916
Buglink: https://bugs.launchpad.net/qemu/+bug/1913917
Reported-by: Alexander Bulekov <alxndr@bu.edu>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20210131103401.217160-1-f4bug@amsat.org

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

 9pfs: fully restart unreclaim loop (cve-2021-20181)

Depending on the client activity, the server can be asked to open a huge
number of file descriptors and eventually hit RLIMIT_NOFILE. This is
currently mitigated using a reclaim logic : the server closes the file
descriptors of idle fids, based on the assumption that it will be able
to re-open them later. This assumption doesn't hold of course if the
client requests the file to be unlinked. In this case, we loop on the
entire fid list and mark all related fids as unreclaimable (the reclaim
logic will just ignore them) and, of course, we open or re-open their
file descriptors if needed since we're about to unlink the file.

This is the purpose of v9fs_mark_fids_unreclaim(). Since the actual
opening of a file can cause the coroutine to yield, another client
request could possibly add a new fid that we may want to mark as
non-reclaimable as well. The loop is thus restarted if the re-open
request was actually transmitted to the backend. This is achieved
by keeping a reference on the first fid (head) before traversing
the list.

This is wrong in several ways:
- a potential clunk request from the client could tear the first
  fid down and cause the reference to be stale. This leads to a
  use-after-free error that can be detected with ASAN, using a
  custom 9p client
- fids are added at the head of the list : restarting from the
  previous head will always miss fids added by a some other
  potential request

All these problems could be avoided if fids were being added at the
end of the list. This can be achieved with a QSIMPLEQ, but this is
probably too much change for a bug fix. For now let's keep it
simple and just restart the loop from the current head.

Fixes: CVE-2021-20181
Buglink: https://bugs.launchpad.net/qemu/+bug/1911666
Reported-by: Zero Day Initiative <zdi-disclosures@trendmicro.com>

tools/virtiofsd/passthrough_ll.c | 73 46 + 27 - 0 !
1 file changed, 46 insertions(+), 27 deletions(-)

 [patch 1/3] virtiofsd: extract lo_do_open() from lo_open()

Both lo_open() and lo_create() have similar code to open a file. Extract
a common lo_do_open() function from lo_open() that will be used by
lo_create() in a later commit.

Since lo_do_open() does not otherwise need fuse_req_t req, convert
lo_add_fd_mapping() to use struct lo_data *lo instead.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20210204150208.367837-2-stefanha@redhat.com>

tools/virtiofsd/passthrough_ll.c | 29 21 + 8 - 0 !
1 file changed, 21 insertions(+), 8 deletions(-)

 [patch 2/3] virtiofsd: optionally return inode pointer from lo_do_lookup()

lo_do_lookup() finds an existing inode or allocates a new one. It
increments nlookup so that the inode stays alive until the client
releases it.

Existing callers don't need the struct lo_inode so the function doesn't
return it. Extend the function to optionally return the inode. The next
commit will need it.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

tools/virtiofsd/passthrough_ll.c | 144 92 + 52 - 0 !
1 file changed, 92 insertions(+), 52 deletions(-)

 [patch 3/3] virtiofsd: prevent opening of special files (cve-2020-35517)
Bug-Debian: https://bugs.debian.org/980814

A well-behaved FUSE client does not attempt to open special files with
FUSE_OPEN because they are handled on the client side (e.g. device nodes
are handled by client-side device drivers).

The check to prevent virtiofsd from opening special files is missing in
a few cases, most notably FUSE_OPEN. A malicious client can cause
virtiofsd to open a device node, potentially allowing the guest to
escape. This can be exploited by a modified guest device driver. It is
not exploitable from guest userspace since the guest kernel will handle
special files inside the guest instead of sending FUSE requests.

This patch fixes this issue by introducing the lo_inode_open() function
to check the file type before opening it. This is a short-term solution
because it does not prevent a compromised virtiofsd process from opening
device nodes on the host.

Restructure lo_create() to try O_CREAT | O_EXCL first. Note that O_CREAT
| O_EXCL does not follow symlinks, so O_NOFOLLOW masking is not
necessary here. If the file exists and the user did not specify O_EXCL,
open it via lo_do_open().

Reported-by: Alex Xu <alex@alxu.ca>
Fixes: CVE-2020-35517

tools/virtiofsd/passthrough_ll.c | 9 5 + 4 - 0 !
1 file changed, 5 insertions(+), 4 deletions(-)

 virtiofsd: save error code early at the failure callsite
Commit-Id: 1e08f164e9fdc9528ad6990012301b9a04b0bc90
Comment: this is preparational patch for CVE-2021-20263

Change error code handling slightly in lo_setattr(). Right now we seem
to jump to out_err and assume that "errno" is valid and use that to
send reply.

But if caller has to do some other operations before jumping to out_err,
then it does the dance of first saving errno to saverr and the restore
errno before jumping to out_err. This makes it more confusing.

I am about to make more changes where caller will have to do some
work after error before jumping to out_err. I found it easier to
change the convention a bit. That is caller saves error in "saverr"
before jumping to out_err. And out_err uses "saverr" to send error
back and does not rely on "errno" having actual error.

v3: Resolved conflicts in lo_setattr() due to lo_inode_open() changes.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>

docs/tools/virtiofsd.rst | 4 4 + 0 - 0 !
tools/virtiofsd/passthrough_ll.c | 77 76 + 1 - 0 !
2 files changed, 80 insertions(+), 1 deletion(-)

 virtiofs: drop remapped security.capability xattr as needed
Bug-Debian: http://bugs.debian.org/985083
Commit-Id: e586edcb410543768ef009eaa22a2d9dd4a53846

On Linux, the 'security.capability' xattr holds a set of
capabilities that can change when an executable is run, giving
a limited form of privilege escalation to those programs that
the writer of the file deemed worthy.

Any write causes the 'security.capability' xattr to be dropped,
stopping anyone from gaining privilege by modifying a blessed
file.

Fuse relies on the daemon to do this dropping, and in turn the
daemon relies on the host kernel to drop the xattr for it.  However,
with the addition of -o xattrmap, the xattr that the guest
stores its capabilities in is now not the same as the one that
the host kernel automatically clears.

Where the mapping changes 'security.capability', explicitly clear
the remapped name to preserve the same behaviour.

This bug is assigned CVE-2021-20263.

Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

include/net/net.h | 5 5 + 0 - 0 !
include/net/queue.h | 8 8 + 0 - 0 !
net/net.c | 38 31 + 7 - 0 !
net/queue.c | 22 22 + 0 - 0 !
4 files changed, 66 insertions(+), 7 deletions(-)

 [patch 01/10] net: introduce qemu_receive_packet()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Commit-Id: 705df5466c98f3efdd2b68d3b31dad86858acad7

Some NIC supports loopback mode and this is done by calling
nc->info->receive() directly which in fact suppresses the effort of
reentrancy check that is done in qemu_net_queue_send().

Unfortunately we can't use qemu_net_queue_send() here since for
loopback there's no sender as peer, so this patch introduce a
qemu_receive_packet() which is used for implementing loopback mode
for a NIC with this check.

NIC that supports loopback mode will be converted to this helper.

This is intended to address CVE-2021-3416.

Cc: Prasad J Pandit <ppandit@redhat.com>

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

 [patch 09/10] cadence_gem: switch to use qemu_receive_packet() for loopback
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Commit-Id: e73adfbeec9d4e008630c814759052ed945c3fed

This patch switches to use qemu_receive_packet() which can detect
reentrancy and return early.

This is intended to address CVE-2021-3416.

Cc: Prasad J Pandit <ppandit@redhat.com>
Cc: qemu-stable@nongnu.org

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

 [patch 03/10] dp8393x: switch to use qemu_receive_packet() for loopback packet
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Commit-Id: 331d2ac9ea307c990dc86e6493e8f0c48d14bb33

This patch switches to use qemu_receive_packet() which can detect
reentrancy and return early.

This is intended to address CVE-2021-3416.

Cc: Prasad J Pandit <ppandit@redhat.com>
Cc: qemu-stable@nongnu.org

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

 [patch 02/10] e1000: switch to use qemu_receive_packet() for loopback
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Commit-Id: 1caff0340f49c93d535c6558a5138d20d475315c

This patch switches to use qemu_receive_packet() which can detect
reentrancy and return early.

This is intended to address CVE-2021-3416.

Cc: Prasad J Pandit <ppandit@redhat.com>
Cc: qemu-stable@nongnu.org

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

 [patch 10/10] lan9118: switch to use qemu_receive_packet() for loopback
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Commit-Id: 37cee01784ff0df13e5209517e1b3594a5e792d1

This patch switches to use qemu_receive_packet() which can detect
reentrancy and return early.

This is intended to address CVE-2021-3416.

Cc: Prasad J Pandit <ppandit@redhat.com>
Cc: qemu-stable@nongnu.org

hw/net/msf2-emac.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 [patch 04/10] msf2-mac: switch to use qemu_receive_packet() for loopback
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Commit-Id: 26194a58f4eb83c5bdf4061a1628508084450ba1

This patch switches to use qemu_receive_packet() which can detect
reentrancy and return early.

This is intended to address CVE-2021-3416.

Cc: Prasad J Pandit <ppandit@redhat.com>
Cc: qemu-stable@nongnu.org

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

 [patch 08/10] pcnet: switch to use qemu_receive_packet() for loopback
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Commit-Id: 99ccfaa1edafd79f7a3a0ff7b58ae4da7c514928

This patch switches to use qemu_receive_packet() which can detect
reentrancy and return early.

This is intended to address CVE-2021-3416.

Cc: Prasad J Pandit <ppandit@redhat.com>
Cc: qemu-stable@nongnu.org
Buglink: https://bugs.launchpad.net/qemu/+bug/1917085

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

 [patch 07/10] rtl8139: switch to use qemu_receive_packet() for loopback
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Commit-Id: 5311fb805a4403bba024e83886fa0e7572265de4

This patch switches to use qemu_receive_packet() which can detect
reentrancy and return early.

This is intended to address CVE-2021-3416.

Cc: Prasad J Pandit <ppandit@redhat.com>
Cc: qemu-stable@nongnu.org
Buglink: https://bugs.launchpad.net/qemu/+bug/1910826

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

 [patch 05/10] sungem: switch to use qemu_receive_packet() for loopback
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Commit-Id: 8c92060d3c0248bd4d515719a35922cd2391b9b4

This patch switches to use qemu_receive_packet() which can detect
reentrancy and return early.

This is intended to address CVE-2021-3416.

Cc: Prasad J Pandit <ppandit@redhat.com>
Cc: qemu-stable@nongnu.org

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

 [patch 06/10] tx_pkt: switch to use qemu_receive_packet_iov() for loopback
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Commit-Id: 8c552542b81e56ff532dd27ec6e5328954bdda73

This patch switches to use qemu_receive_receive_iov() which can detect
reentrancy and return early.

This is intended to address CVE-2021-3416.

Cc: Prasad J Pandit <ppandit@redhat.com>
Cc: qemu-stable@nongnu.org

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

 e1000: fail early for evil descriptor
Commit-Id: 3de46e6fc489c52c9431a8a832ad8170a7569bd8
Bug-Debian: https://bugs.debian.org/984450

During procss_tx_desc(), driver can try to chain data descriptor with
legacy descriptor, when will lead underflow for the following
calculation in process_tx_desc() for bytes:

            if (tp->size + bytes > msh)
                bytes = msh - tp->size;

This will lead a infinite loop. So check and fail early if tp->size if
greater or equal to msh.

Reported-by: Alexander Bulekov <alxndr@bu.edu>
Reported-by: Cheolwoo Myung <cwmyung@snu.ac.kr>
Reported-by: Ruhr-University Bochum <bugs-syssec@rub.de>
Cc: Prasad J Pandit <ppandit@redhat.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Jason Wang <jasowang@redhat.com>