Debian Patches

Status for qemu/1:5.2+dfsg-11+deb11u2

Patch Description Author Forwarded Bugs Origin Last update
microvm-default-machine-type.patch set default machine type to be microvm if CONFIG_MICROVM is defined
diff --git a/hw/i386/microvm.c b/hw/i386/microvm.c
index def37e60f79..35b948ffb11 100644
Michael Tokarev <mjt@tls.msk.ru> no 2020-02-22
use-fixed-data-path.patch use fixed data dir instead of determining it at runtime
Since we install to a fixed location, use fixed data directory
instead of deriving it at runtime from executable path.
This way it is possible to move qemu binary to another directory
and it will still work.

diff --git a/softmmu/vl.c b/softmmu/vl.c
index e6e0ad5a925..de716a8635b 100644
Michael Tokarev <mjt@tls.msk.ru> no
build-most-modules-statically-hack.diff 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.

diff --git a/meson.build b/meson.build
index e3386196ba..a28f7d10f1 100644
Michael Tokarev <mjt@tls.msk.ru> no
skip-meson-pc-bios.diff 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.

diff --git a/meson.build b/meson.build
Michael Tokarev <mjt@tls.msk.ru> no
linux-user-binfmt-P.diff [PATCH, HACK]: linux-user: handle binfmt-misc P flag as a separate exe name
A hackish way to distinguish the case when qemu-user binary is executed
using in-kernel binfmt-misc subsystem with P flag (preserve argv).
We register binfmt interpreter under name /usr/libexec/qemu-binfmt/qemu-foo-binfmt-P
(which is just a symlink to ../../bin/qemu-foo), and if run like that,
qemu-user binary will "know" it should interpret argv[1] & argv[2]
in a special way.

diff --git a/linux-user/main.c b/linux-user/main.c
index 24d1eb73ad..5596dab9be 100644
Michael Tokarev <mjt@tls.msk.ru> no 2021-02-13
openbios-address-of-packet-member.patch diff --git a/roms/openbios/drivers/usbohci.c b/roms/openbios/drivers/usbohci.c
index 774164b..42788a2 100644
no
openbios-use-source_date_epoch-in-makefile.patch 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.
Vagrant Cascadian <vagrant@reproducible-builds.org> no 2020-06-21
seabios-hppa-use-consistent-date-and-remove-hostname.patch 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/
Vagrant Cascadian <vagrant@reproducible-builds.org> no 2020-06-21
slof-remove-user-and-host-from-release-version.patch roms/SLOF/Makefile.gen: Remove user and host from release version.
This version string ends up in the slof.bin, leading to
reproducibility issues.
Vagrant Cascadian <vagrant@reproducible-builds.org> no 2020-06-22
slof-ensure-ld-is-called-with-C-locale.patch slof/Makefile.gen: Ensure ld is called with the C locale.
The output of "ld -V" changes based on the environment's locale.
Vagrant Cascadian <vagrant@reproducible-builds.org> no 2020-06-22
spelling.diff Various spelling fixes
An assorted set of spelling fixes

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 90e63b83674..2b096552719 100644
Michael Tokarev <mjt@tls.msk.ru> no
pc-bios-descriptors-fix-paths-in-json-files.patch pc-bios/descriptors: fix paths in json files
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).
Sergei Trofimovich <slyfox@gentoo.org> yes upstream 2021-01-31
i386-acpi-restore-device-paths-for-pre-5.1-vms.patch i386/acpi: restore device paths for pre-5.1 vms
After fixing the _UID value for the primary PCI root bridge in
af1b80ae it was discovered that this change updates Windows
configuration in an incompatible way causing network configuration
failure unless DHCP is used. More details provided on the list:

https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg08484.html

This change reverts the _UID update from 1 to 0 for q35 and i440fx
VMs before version 5.2 to maintain the original behaviour when
upgrading.
Vitaly Cheptsov <cheptsov@ispras.ru> no debian 2021-03-01
linux-user-elfload-fix-address-calculation-in-fallback-scenario.patch linux-user/elfload: fix address calculation in fallback scenario
Previously, guest_loaddr was not taken into account when returning an
address from pgb_find_hole when /proc/self/maps was unavailable which
caused an improper guest_base address to be calculated.

This could cause a SIGSEGV later in load_elf_image -> target_mmap for
ET_EXEC type images since the mmap MAP_FIXED flag is specified which
could clobber existing mappings at the address returnd by g2h().

mmap(0xd87000, 16846912, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE|0x100000, -1, 0) = 0xd87000
munmap(0xd87000, 16846912) = 0
write(2, "Locating guest address space @ 0"..., 40Locating guest address space @ 0xd87000) = 40
mmap(0x1187000, 16850944, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x1187000
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x2188310} ---
+++ killed by SIGSEGV +++

Now, pgd_find_hole accounts for guest_loaddr in this scenario.

[lv: updated it to check if ret == -1]
Vincent Fazio <vfazio@gmail.com> no debian 2021-01-31
memory-clamp-cached-translation-if-points-to-MMIO-region-CVE-2020-27821.patch memory: clamp cached translation in case it points to an MMIO region
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
* decode to completely different MemoryRegions. When such registers
* exist (e.g. I/O ports 0xcf8 and 0xcf9 on most PC chipsets), MMIO
* regions overlap wildly. For this reason we cannot clamp the accesses
* here.
*
* If the length is small (as is the case for address_space_ldl/stl),
* everything works fine. If the incoming length is large, however,
* the caller really has to do the clamping through memory_access_size.
*/

address_space_cache_init is exactly one such case where "the incoming length
is large", therefore we need to clamp the resulting length---not to
memory_access_size though, since we are not doing an access yet, but to
the size of the resulting section. This ensures that subsequent accesses
to the cached MemoryRegionSection will be in range.

With this patch, the enclosed testcase notices that the used ring does
not fit into the MSI-X table and prints a "qemu-system-x86_64: Cannot map used"
error.
Paolo Bonzini <pbonzini@redhat.com> yes debian upstream 2020-12-01
virtiofsd-optionally-return-inode-pointer-from-lo_do_lookup.patch [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.
Stefan Hajnoczi <stefanha@redhat.com> no 2021-02-04
configure-replace-enable-disable-git-update-with-wit.patch [PATCH] configure: replace --enable/disable-git-update with --with-git-submodules

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.
Dan Streetman <ddstreet@canonical.com> no 2021-01-19
arm_gic-fix-interrupt-ID-in-GICD_SGIR-CVE-2021-20221.patch hw/intc/arm_gic: Fix interrupt ID in GICD_SGIR register
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.)
Philippe Mathieu-Daudé <f4bug@amsat.org> no 2021-01-31
9pfs-Fully-restart-unreclaim-loop-CVE-2021-20181.patch 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.
Greg Kurz <groug@kaod.org> no 2021-01-14
virtiofsd-extract-lo_do_open-from-lo_open.patch [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.
Stefan Hajnoczi <stefanha@redhat.com> no 2021-02-04
virtiofsd-prevent-opening-of-special-files-CVE-2020-35517.patch [PATCH 3/3] virtiofsd: prevent opening of special files (CVE-2020-35517)
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().
Stefan Hajnoczi <stefanha@redhat.com> no debian 2021-02-04
virtiofsd-save-error-code-early-at-the-failure-callsite.patch virtiofsd: Save error code early at the failure callsite
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.
Vivek Goyal <vgoyal@redhat.com> no 2021-02-08
virtiofsd-drop-remapped-security.capability-xattr-as-needed-CVE-2021-20263.patch virtiofs: drop remapped security.capability xattr as needed
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.
"Dr. David Alan Gilbert" <dgilbert@redhat.com> no debian 2021-02-24
net-qemu_receive_packet-for-loopback-introduce.patch [PATCH 01/10] net: introduce qemu_receive_packet()
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.
Jason Wang <jasowang@redhat.com> no 2021-02-24
net-qemu_receive_packet-for-loopback-cadence_gem.patch [PATCH 09/10] cadence_gem: switch to use qemu_receive_packet() for loopback
This patch switches to use qemu_receive_packet() which can detect
reentrancy and return early.

This is intended to address CVE-2021-3416.
Alexander Bulekov <alxndr@bu.edu> no 2021-03-01
net-qemu_receive_packet-for-loopback-dp8393x.patch [PATCH 03/10] dp8393x: switch to use qemu_receive_packet() for loopback packet
This patch switches to use qemu_receive_packet() which can detect
reentrancy and return early.

This is intended to address CVE-2021-3416.
Jason Wang <jasowang@redhat.com> no 2021-02-24
net-qemu_receive_packet-for-loopback-e1000.patch [PATCH 02/10] e1000: switch to use qemu_receive_packet() for loopback
This patch switches to use qemu_receive_packet() which can detect
reentrancy and return early.

This is intended to address CVE-2021-3416.
Jason Wang <jasowang@redhat.com> no 2021-02-24
net-qemu_receive_packet-for-loopback-lan9118.patch [PATCH 10/10] lan9118: switch to use qemu_receive_packet() for loopback
This patch switches to use qemu_receive_packet() which can detect
reentrancy and return early.

This is intended to address CVE-2021-3416.
Alexander Bulekov <alxndr@bu.edu> no 2021-03-01
net-qemu_receive_packet-for-loopback-msf2.patch [PATCH 04/10] msf2-mac: switch to use qemu_receive_packet() for loopback
This patch switches to use qemu_receive_packet() which can detect
reentrancy and return early.

This is intended to address CVE-2021-3416.
Jason Wang <jasowang@redhat.com> no 2021-02-24
net-qemu_receive_packet-for-loopback-pcnet.patch [PATCH 08/10] pcnet: switch to use qemu_receive_packet() for loopback
This patch switches to use qemu_receive_packet() which can detect
reentrancy and return early.

This is intended to address CVE-2021-3416.
Alexander Bulekov <alxndr@bu.edu> no 2021-03-01
net-qemu_receive_packet-for-loopback-rtl8139.patch [PATCH 07/10] rtl8139: switch to use qemu_receive_packet() for loopback
This patch switches to use qemu_receive_packet() which can detect
reentrancy and return early.

This is intended to address CVE-2021-3416.
Alexander Bulekov <alxndr@bu.edu> no 2021-02-26
net-qemu_receive_packet-for-loopback-sungem.patch [PATCH 05/10] sungem: switch to use qemu_receive_packet() for loopback
This patch switches to use qemu_receive_packet() which can detect
reentrancy and return early.

This is intended to address CVE-2021-3416.
Jason Wang <jasowang@redhat.com> no 2021-02-24
net-qemu_receive_packet-for-loopback-tx_pkt-iov.patch [PATCH 06/10] tx_pkt: switch to use qemu_receive_packet_iov() for loopback
This patch switches to use qemu_receive_receive_iov() which can detect
reentrancy and return early.

This is intended to address CVE-2021-3416.
Jason Wang <jasowang@redhat.com> no 2021-02-24
net-e1000-fail-early-for-evil-descriptor-CVE-2021-20257.patch e1000: fail early for evil descriptor
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.
Jason Wang <jasowang@redhat.com> no debian 2021-02-24
sdhci/dont-transfer-any-data-when-command-time-out.patch [PATCH 1/5] hw/sd: sdhci: Don't transfer any data when command time out
At the end of sdhci_send_command(), it starts a data transfer if the
command register indicates data is associated. But the data transfer
should only be initiated when the command execution has succeeded.

With this fix, the following reproducer:

outl 0xcf8 0x80001810
outl 0xcfc 0xe1068000
outl 0xcf8 0x80001804
outw 0xcfc 0x7
write 0xe106802c 0x1 0x0f
write 0xe1068004 0xc 0x2801d10101fffffbff28a384
write 0xe106800c 0x1f 0x9dacbbcad9e8f7061524334251606f7e8d9cabbac9d8e7f60514233241505f
write 0xe1068003 0x28 0x80d000251480d000252280d000253080d000253e80d000254c80d000255a80d000256880d0002576
write 0xe1068003 0x1 0xfe

cannot be reproduced with the following QEMU command line:

$ qemu-system-x86_64 -nographic -M pc-q35-5.0 \
-device sdhci-pci,sd-spec-version=3 \
-drive if=sd,index=0,file=null-co://,format=raw,id=mydrive \
-device sd-card,drive=mydrive \
-monitor none -serial none -qtest stdio
Bin Meng <bmeng.cn@gmail.com> no 2021-03-03
sdhci/dont-write-to-SDHC_SYSAD-register-when-transfer-is-in-progress.patch [PATCH 2/5] hw/sd: sdhci: Don't write to SDHC_SYSAD register when transfer is in progress
Per "SD Host Controller Standard Specification Version 7.00"
chapter 2.2.1 SDMA System Address Register:

This register can be accessed only if no transaction is executing
(i.e., after a transaction has stopped).

With this fix, the following reproducer:

outl 0xcf8 0x80001010
outl 0xcfc 0xfbefff00
outl 0xcf8 0x80001001
outl 0xcfc 0x06000000
write 0xfbefff2c 0x1 0x05
write 0xfbefff0f 0x1 0x37
write 0xfbefff0a 0x1 0x01
write 0xfbefff0f 0x1 0x29
write 0xfbefff0f 0x1 0x02
write 0xfbefff0f 0x1 0x03
write 0xfbefff04 0x1 0x01
write 0xfbefff05 0x1 0x01
write 0xfbefff07 0x1 0x02
write 0xfbefff0c 0x1 0x33
write 0xfbefff0e 0x1 0x20
write 0xfbefff0f 0x1 0x00
write 0xfbefff2a 0x1 0x01
write 0xfbefff0c 0x1 0x00
write 0xfbefff03 0x1 0x00
write 0xfbefff05 0x1 0x00
write 0xfbefff2a 0x1 0x02
write 0xfbefff0c 0x1 0x32
write 0xfbefff01 0x1 0x01
write 0xfbefff02 0x1 0x01
write 0xfbefff03 0x1 0x01

cannot be reproduced with the following QEMU command line:

$ qemu-system-x86_64 -nographic -machine accel=qtest -m 512M \
-nodefaults -device sdhci-pci,sd-spec-version=3 \
-drive if=sd,index=0,file=null-co://,format=raw,id=mydrive \
-device sd-card,drive=mydrive -qtest stdio
Bin Meng <bmeng.cn@gmail.com> no 2021-03-03
sdhci/correctly-set-the-controller-status-for-ADMA.patch [PATCH 3/5] hw/sd: sdhci: Correctly set the controller status for ADMA
When an ADMA transfer is started, the codes forget to set the
controller status to indicate a transfer is in progress.

With this fix, the following 2 reproducers:

https://paste.debian.net/plain/1185136
https://paste.debian.net/plain/1185141

cannot be reproduced with the following QEMU command line:

$ qemu-system-x86_64 -nographic -machine accel=qtest -m 512M \
-nodefaults -device sdhci-pci,sd-spec-version=3 \
-drive if=sd,index=0,file=null-co://,format=raw,id=mydrive \
-device sd-card,drive=mydrive -qtest stdio
Bin Meng <bmeng.cn@gmail.com> no 2021-03-03
sdhci/limit-block-size-only-when-SDHC_BLKSIZE-register-is-writable.patch [PATCH 4/5] hw/sd: sdhci: Limit block size only when SDHC_BLKSIZE register is writable
The codes to limit the maximum block size is only necessary when
SDHC_BLKSIZE register is writable.
Bin Meng <bmeng.cn@gmail.com> no 2021-03-03
sdhci/reset-the-data-pointer-of-s-fifo_buffer-when-a-different-block-size-is-programmed.patch [PATCH 5/5] hw/sd: sdhci: Reset the data pointer of s->fifo_buffer[] when a different block size is programmed
If the block size is programmed to a different value from the
previous one, reset the data pointer of s->fifo_buffer[] so that
s->fifo_buffer[] can be filled in using the new block size in
the next transfer.

With this fix, the following reproducer:

outl 0xcf8 0x80001010
outl 0xcfc 0xe0000000
outl 0xcf8 0x80001001
outl 0xcfc 0x06000000
write 0xe000002c 0x1 0x05
write 0xe0000005 0x1 0x02
write 0xe0000007 0x1 0x01
write 0xe0000028 0x1 0x10
write 0x0 0x1 0x23
write 0x2 0x1 0x08
write 0xe000000c 0x1 0x01
write 0xe000000e 0x1 0x20
write 0xe000000f 0x1 0x00
write 0xe000000c 0x1 0x32
write 0xe0000004 0x2 0x0200
write 0xe0000028 0x1 0x00
write 0xe0000003 0x1 0x40

cannot be reproduced with the following QEMU command line:

$ qemu-system-x86_64 -nographic -machine accel=qtest -m 512M \
-nodefaults -device sdhci-pci,sd-spec-version=3 \
-drive if=sd,index=0,file=null-co://,format=raw,id=mydrive \
-device sd-card,drive=mydrive -qtest stdio
Bin Meng <bmeng.cn@gmail.com> no 2021-03-03
mptsas-remove-unused-MPTSASState.pending-CVE-2021-3392.patch mptsas: remove unused MPTSASState.pending (CVE-2021-3392)
During previous attempt to fix CVE-2021-3392 it was discovered
that MPTSASState.pending is actually not used. So instead of
fixing the prob, just remove the offending code entirely
Michael Tokarev <mjt@tls.msk.ru> no debian 2021-04-16
pvrdma-fix-possible-mremap-overflow-in-pvrdma-device-CVE-2021-3582.patch hw/rdma: Fix possible mremap overflow in the pvrdma device (CVE-2021-3582)
Ensure mremap boundaries not trusting the guest kernel to
pass the correct buffer length.
Marcel Apfelbaum <marcel@redhat.com> no debian 2021-06-16
pvrdma-ensure-correct-input-on-ring-init-CVE-2021-3607.patch pvrdma: Ensure correct input on ring init (CVE-2021-3607)
Check the guest passed a non zero page count
for pvrdma device ring buffers.
Marcel Apfelbaum <marcel.apfelbaum@gmail.com> no debian 2021-06-30
pvrdma-fix-the-ring-init-error-flow-CVE-2021-3608.patch pvrdma: Fix the ring init error flow (CVE-2021-3608)
Do not unmap uninitialized dma addresses.
Marcel Apfelbaum <marcel.apfelbaum@gmail.com> no debian 2021-06-30
ide-atapi-check-logical-block-address-and-read-size-CVE-2020-29443.patch ide: atapi: check logical block address and read size (CVE-2020-29443)
While processing ATAPI cmd_read/cmd_read_cd commands,
Logical Block Address (LBA) maybe invalid OR closer to the last block,
leading to an OOB access issues. Add range check to avoid it.
Prasad J Pandit <pjp@fedoraproject.org> no debian 2021-01-18
usb-limit-combined-packets-to-1-MiB-CVE-2021-3527.patch usb: limit combined packets to 1 MiB (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.
Gerd Hoffmann <kraxel@redhat.com> no debian 2021-05-03
usb-redir-avoid-dynamic-stack-allocation-CVE-2021-3527.patch usb/redir: avoid dynamic stack allocation (CVE-2021-3527)
Use autofree heap allocation instead.
Gerd Hoffmann <kraxel@redhat.com> no debian 2021-05-03
usbredir-fix-free-call-CVE-2021-3682.patch usbredir: fix free call
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.
Gerd Hoffmann <kraxel@redhat.com> no debian 2021-07-22
uas-add-stream-number-sanity-checks-CVE-2021-3713.patch uas: add stream number sanity checks.
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.
Gerd Hoffmann <kraxel@redhat.com> no debian 2021-08-18
virtio-net-fix-use-after-unmap-free-for-sg-CVE-2021-3748.patch virtio-net: fix use after unmap/free for sg
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.
Jason Wang <jasowang@redhat.com> no debian 2021-09-02
virtio-net-fix-map-leaking-on-error-during-receive-CVE-2022-26353.patch virtio-net: fix map leaking on error during receive
Commit bedd7e93d0196 ("virtio-net: fix use after unmap/free for sg")
tries to fix the use after free of the sg by caching the virtqueue
elements in an array and unmap them at once after receiving the
packets, But it forgot to unmap the cached elements on error which
will lead to leaking of mapping and other unexpected results.

Fixing this by detaching the cached elements on error. This addresses
CVE-2022-26353.
Jason Wang <jasowang@redhat.com> no 2022-03-08
ati_2d-fix-buffer-overflow-in-ati_2d_blt-CVE-2021-3638.patch hw/display/ati_2d: Fix buffer overflow in ati_2d_blt (CVE-2021-3638)
When building QEMU with DEBUG_ATI defined then running with
'-device ati-vga,romfile="" -d unimp,guest_errors -trace ati\*'
we get:

ati_mm_write 4 0x16c0 DP_CNTL <- 0x1
ati_mm_write 4 0x146c DP_GUI_MASTER_CNTL <- 0x2
ati_mm_write 4 0x16c8 DP_MIX <- 0xff0000
ati_mm_write 4 0x16c4 DP_DATATYPE <- 0x2
ati_mm_write 4 0x224 CRTC_OFFSET <- 0x0
ati_mm_write 4 0x142c DST_PITCH_OFFSET <- 0xfe00000
ati_mm_write 4 0x1420 DST_Y <- 0x3fff
ati_mm_write 4 0x1410 DST_HEIGHT <- 0x3fff
ati_mm_write 4 0x1588 DST_WIDTH_X <- 0x3fff3fff
ati_2d_blt: vram:0x7fff5fa00000 addr:0 ds:0x7fff61273800 stride:2560 bpp:32 rop:0xff
ati_2d_blt: 0 0 0, 0 127 0, (0,0) -> (16383,16383) 16383x16383 > ^
ati_2d_blt: pixman_fill(dst:0x7fff5fa00000, stride:254, bpp:8, x:16383, y:16383, w:16383, h:16383, xor:0xff000000)
Thread 3 "qemu-system-i38" received signal SIGSEGV, Segmentation fault.
(gdb) bt
#0 0x00007ffff7f62ce0 in sse2_fill.lto_priv () at /lib64/libpixman-1.so.0
#1 0x00007ffff7f09278 in pixman_fill () at /lib64/libpixman-1.so.0
#2 0x0000555557b5a9af in ati_2d_blt (s=0x631000028800) at hw/display/ati_2d.c:196
#3 0x0000555557b4b5a2 in ati_mm_write (opaque=0x631000028800, addr=5512, data=1073692671, size=4) at hw/display/ati.c:843
#4 0x0000555558b90ec4 in memory_region_write_accessor (mr=0x631000039cc0, addr=5512, ..., size=4, ...) at softmmu/memory.c:492

Commit 584acf34cb0 ("ati-vga: Fix reverse bit blts") introduced
the local dst_x and dst_y which adjust the (x, y) coordinates
depending on the direction in the SRCCOPY ROP3 operation, but
forgot to address the same issue for the PATCOPY, BLACKNESS and
WHITENESS operations, which also call pixman_fill().

Fix that now by using the adjusted coordinates in the pixman_fill
call, and update the related debug printf().
"Philippe Mathieu-Daudé" <philmd@redhat.com> no debian 2021-09-06
vhost-user-gpu/fix-memory-disclosure-in-virgl_cmd_get_capset_info-CVE-2021-3545.patch vhost-user-gpu: fix memory disclosure in virgl_cmd_get_capset_info (CVE-2021-3545)
Otherwise some of the 'resp' will be leaked to guest.

virtio-gpu fix: 42a8dadc74 ("virtio-gpu: fix information leak
in getting capset info dispatch")
Li Qiang <liq3ea@163.com> no debian 2021-05-15
vhost-user-gpu/fix-resource-leak-in-vg_resource_create_2d-CVE-2021-3544.patch vhost-user-gpu: fix resource leak in 'vg_resource_create_2d' (CVE-2021-3544)
Call 'vugbm_buffer_destroy' in error path to avoid resource leak.
Li Qiang <liq3ea@163.com> no debian 2021-05-15
vhost-user-gpu/fix-memory-leak-in-vg_resource_attach_backing-CVE-2021-3544.patch vhost-user-gpu: fix memory leak in vg_resource_attach_backing (CVE-2021-3544)
Check whether the 'res' has already been attach_backing to avoid
memory leak.

virtio-gpu fix: 204f01b309 ("virtio-gpu: fix memory leak
in resource attach backing")
Li Qiang <liq3ea@163.com> no debian 2021-05-15
vhost-user-gpu/fix-memory-leak-while-calling-vg_resource_unref-CVE-2021-3544.patch vhost-user-gpu: fix memory leak while calling 'vg_resource_unref' (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.

virtio-gpu fix: 5e8e3c4c75 ("virtio-gpu: fix resource leak
in virgl_cmd_resource_unref")
Li Qiang <liq3ea@163.com> no debian 2021-05-15
vhost-user-gpu/fix-memory-leak-in-virgl_cmd_resource_unref-CVE-2021-3544.patch vhost-user-gpu: fix memory leak in 'virgl_cmd_resource_unref' (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.

virtio-gpu fix: 5e8e3c4c75 ("virtio-gpu: fix resource leak
in virgl_cmd_resource_unref"
Li Qiang <liq3ea@163.com> no debian 2021-05-15
vhost-user-gpu/fix-memory-leak-in-virgl_resource_attach_backing-CVE-2021-3544.patch vhost-user-gpu: fix memory leak in 'virgl_resource_attach_backing' (CVE-2021-3544)
If 'virgl_renderer_resource_attach_iov' failed, the 'res_iovs' will
be leaked.

virtio-gpu fix: 33243031da ("virtio-gpu-3d: fix memory leak
in resource attach backing")
Li Qiang <liq3ea@163.com> no debian 2021-05-15
vhost-user-gpu/fix-OOB-write-in-virgl_cmd_get_capset-CVE-2021-3546.patch vhost-user-gpu: fix OOB write in 'virgl_cmd_get_capset' (CVE-2021-3546)
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")
Li Qiang <liq3ea@163.com> no debian 2021-05-15
ui-cursor-fix-integer-overflow-in-cursor_alloc-CVE-2021-4206.patch ui/cursor: fix integer overflow in cursor_alloc (CVE-2021-4206)
Prevent potential integer overflow by limiting 'width' and 'height' to
512x512. Also change 'datasize' type to size_t. Refer to security
advisory https://starlabs.sg/advisories/22-4206/ for more information.
Mauro Matteo Cascella <mcascell@redhat.com> no 2022-04-07
display-qxl-render-fix-race-condition-in-qxl_cursor-CVE-2021-4207.patch display/qxl-render: fix race condition in qxl_cursor (CVE-2021-4207)
Avoid fetching 'width' and 'height' a second time to prevent possible
race condition. Refer to security advisory
https://starlabs.sg/advisories/22-4207/ for more information.
Mauro Matteo Cascella <mcascell@redhat.com> no 2022-04-07
virtiofsd-drop-membership-of-all-supplementary-group-CVE-2022-0358.patch virtiofsd: Drop membership of all supplementary groups (CVE-2022-0358)
At the start, drop membership of all supplementary groups. This is
not required.

If we have membership of "root" supplementary group and when we switch
uid/gid using setresuid/setsgid, we still retain membership of existing
supplemntary groups. And that can allow some operations which are not
normally allowed.

For example, if root in guest creates a dir as follows.

$ mkdir -m 03777 test_dir

This sets SGID on dir as well as allows unprivileged users to write into
this dir.

And now as unprivileged user open file as follows.

$ su test
$ fd = open("test_dir/priviledge_id", O_RDWR|O_CREAT|O_EXCL, 02755);

This will create SGID set executable in test_dir/.

And that's a problem because now an unpriviliged user can execute it,
get egid=0 and get access to resources owned by "root" group. This is
privilege escalation.

dgilbert: Fixed missing {}'s style nit
Vivek Goyal <vgoyal@redhat.com> no 2022-01-25
vhost-vsock-detach-the-virqueue-element-on-error-CVE-2022-26354.patch vhost-vsock: detach the virqueue element in case of error
In vhost_vsock_common_send_transport_reset(), if an element popped from
the virtqueue is invalid, we should call virtqueue_detach_element() to
detach it from the virtqueue before freeing its memory.
Stefano Garzarella <sgarzare@redhat.com> no 2022-02-28

All known versions for source package 'qemu'

Links