Package: qemu / 1:5.2+dfsg-11+deb11u3

Metadata

Package Version Patches format
qemu 1:5.2+dfsg-11+deb11u3 3.0 (quilt)

Patch series

view the series file
Patch File delta Description
use fixed data path.patch | (download)

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
microvm default machine type.patch | (download)

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
build most modules statically hack.diff | (download)

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.

skip meson pc bios.diff | (download)

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 binfmt P.diff | (download)

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
openbios address of packet member.patch | (download)

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

---
openbios use source_date_epoch in makefile.patch | (download)

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.


seabios hppa use consistent date and remove hostname.patch | (download)

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/


slof remove user and host from release version.patch | (download)

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.


slof ensure ld is called with C locale.patch | (download)

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.


spelling.diff | (download)

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 fix paths in json files.patch | (download)

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 Glckert <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>

i386 acpi restore device paths for pre 5.1 vms.patch | (download)

hw/i386/acpi-build.c | 4 2 + 2 - 0 !
hw/i386/pc_piix.c | 2 2 + 0 - 0 !
hw/i386/pc_q35.c | 2 2 + 0 - 0 !
include/hw/i386/pc.h | 1 1 + 0 - 0 !
4 files changed, 7 insertions(+), 2 deletions(-)

 i386/acpi: restore device paths for pre-5.1 vms
Bug-Debian: http://bugs.debian.org/990675

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.

Cc: qemu-stable@nongnu.org
Cc: qemu-devel@nongnu.org
Reported-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Suggested-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Vitaly Cheptsov <cheptsov@ispras.ru>
Message-Id: <20210301195919.9333-1-cheptsov@ispras.ru>
Tested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
linux user elfload fix address calculation in fallback scenario.patch | (download)

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

 linux-user/elfload: fix address calculation in fallback scenario
Bug-Debian: https://bugs.debian.org/988174

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
  
memory clamp cached translation if points to MMIO region CVE 2020 27821.patch | (download)

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
configure replace enable disable git update with wit.patch | (download)

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>

arm_gic fix interrupt ID in GICD_SGIR CVE 2021 20221.patch | (download)

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
9pfs Fully restart unreclaim loop CVE 2021 20181.patch | (download)

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>
virtiofsd extract lo_do_open from lo_open.patch | (download)

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>
virtiofsd optionally return inode pointer from lo_do_lookup.patch | (download)

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>
virtiofsd prevent opening of special files CVE 2020 35517.patch | (download)

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
virtiofsd save error code early at the failure callsite.patch | (download)

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>
virtiofsd drop remapped security.capability xattr as needed CVE 2021 20263.patch | (download)

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>
net qemu_receive_packet for loopback introduce.patch | (download)

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>
net qemu_receive_packet for loopback cadence_gem.patch | (download)

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
net qemu_receive_packet for loopback dp8393x.patch | (download)

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
net qemu_receive_packet for loopback e1000.patch | (download)

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
net qemu_receive_packet for loopback lan9118.patch | (download)

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
net qemu_receive_packet for loopback msf2.patch | (download)

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
net qemu_receive_packet for loopback pcnet.patch | (download)

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
net qemu_receive_packet for loopback rtl8139.patch | (download)

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
net qemu_receive_packet for loopback sungem.patch | (download)

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
net qemu_receive_packet for loopback tx_pkt iov.patch | (download)

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
net e1000 fail early for evil descriptor CVE 2021 20257.patch | (download)

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>

sdhci/dont transfer any data when command time out.patch | (download)

hw/sd/sdhci.c | 4 3 + 1 - 0 !
1 file changed, 3 insertions(+), 1 deletion(-)

 [patch 1/5] hw/sd: sdhci: don't transfer any data when command time out
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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

Cc: qemu-stable@nongnu.org
Fixes: CVE-2020-17380
Fixes: CVE-2020-25085
Fixes: CVE-2021-3409
Fixes: d7dfca0807a0 ("hw/sdhci: introduce standard SD host controller")
Reported-by: Alexander Bulekov <alxndr@bu.edu>
Reported-by: Cornelius Aschermann (Ruhr-Universitt Bochum)
Reported-by: Sergej Schumilo (Ruhr-Universitt Bochum)
Reported-by: Simon Wrner (Ruhr-Universitt Bochum)
Buglink: https://bugs.launchpad.net/qemu/+bug/1892960
Buglink: https://bugs.launchpad.net/qemu/+bug/1909418
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1928146
sdhci/dont write to SDHC_SYSAD register when transfer is in progress.patch | (download)

hw/sd/sdhci.c | 20 11 + 9 - 0 !
1 file changed, 11 insertions(+), 9 deletions(-)

 [patch 2/5] hw/sd: sdhci: don't write to sdhc_sysad register when transfer is in progress
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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

Cc: qemu-stable@nongnu.org
Fixes: CVE-2020-17380
Fixes: CVE-2020-25085
Fixes: CVE-2021-3409
Fixes: d7dfca0807a0 ("hw/sdhci: introduce standard SD host controller")
Reported-by: Alexander Bulekov <alxndr@bu.edu>
Reported-by: Cornelius Aschermann (Ruhr-Universitt Bochum)
Reported-by: Sergej Schumilo (Ruhr-Universitt Bochum)
Reported-by: Simon Wrner (Ruhr-Universitt Bochum)
Buglink: https://bugs.launchpad.net/qemu/+bug/1892960
Buglink: https://bugs.launchpad.net/qemu/+bug/1909418
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1928146
Tested-by: Alexander Bulekov <alxndr@bu.edu>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Message-Id: <20210303122639.20004-3-bmeng.cn@gmail.com>
Signed-off-by: Philippe Mathieu-Daud <f4bug@amsat.org>

sdhci/correctly set the controller status for ADMA.patch | (download)

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

 [patch 3/5] hw/sd: sdhci: correctly set the controller status for adma
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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

Cc: qemu-stable@nongnu.org
Fixes: CVE-2020-17380
Fixes: CVE-2020-25085
Fixes: CVE-2021-3409
Fixes: d7dfca0807a0 ("hw/sdhci: introduce standard SD host controller")
Reported-by: Alexander Bulekov <alxndr@bu.edu>
Reported-by: Cornelius Aschermann (Ruhr-Universitt Bochum)
Reported-by: Sergej Schumilo (Ruhr-Universitt Bochum)
Reported-by: Simon Wrner (Ruhr-Universitt Bochum)
Buglink: https://bugs.launchpad.net/qemu/+bug/1892960
Buglink: https://bugs.launchpad.net/qemu/+bug/1909418
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1928146
Tested-by: Alexander Bulekov <alxndr@bu.edu>
sdhci/limit block size only when SDHC_BLKSIZE register is writable.patch | (download)

hw/sd/sdhci.c | 14 7 + 7 - 0 !
1 file changed, 7 insertions(+), 7 deletions(-)

 [patch 4/5] hw/sd: sdhci: limit block size only when sdhc_blksize register is writable
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The codes to limit the maximum block size is only necessary when
SDHC_BLKSIZE register is writable.

Tested-by: Alexander Bulekov <alxndr@bu.edu>
sdhci/reset the data pointer of s fifo_buffer when a different block size is programmed.patch | (download)

hw/sd/sdhci.c | 12 12 + 0 - 0 !
1 file changed, 12 insertions(+)

 [patch 5/5] hw/sd: sdhci: reset the data pointer of s->fifo_buffer[] when a different block size is programmed
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

mptsas remove unused MPTSASState.pending CVE 2021 3392.patch | (download)

hw/scsi/mptsas.c | 4 0 + 4 - 0 !
hw/scsi/mptsas.h | 1 0 + 1 - 0 !
2 files changed, 5 deletions(-)

 mptsas: remove unused mptsasstate.pending (cve-2021-3392)
Bug-Debian: http://bugs.debian.org/984449

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

Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Cc: Prasad J Pandit <pjp@fedoraproject.org>
Cc: qemu-stable@nongnu.org

pvrdma fix possible mremap overflow in pvrdma device CVE 2021 3582.patch | (download)

hw/rdma/vmw/pvrdma_cmd.c | 7 7 + 0 - 0 !
1 file changed, 7 insertions(+)

 hw/rdma: fix possible mremap overflow in the pvrdma device (cve-2021-3582)
Bug-Debian: https://bugs.debian.org/990565

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

Fixes: CVE-2021-3582
Reported-by: VictorV (Kunlun Lab) <vv474172261@gmail.com>
Tested-by: VictorV (Kunlun Lab) <vv474172261@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel@redhat.com>
Message-Id: <20210616110600.20889-1-marcel.apfelbaum@gmail.com>
pvrdma ensure correct input on ring init CVE 2021 3607.patch | (download)

hw/rdma/vmw/pvrdma_main.c | 5 5 + 0 - 0 !
1 file changed, 5 insertions(+)

 pvrdma: ensure correct input on ring init (cve-2021-3607)
Bug-Debian: https://bugs.debian.org/990564

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

Fixes: CVE-2021-3607
Reported-by: VictorV (Kunlun Lab) <vv474172261@gmail.com>
pvrdma fix the ring init error flow CVE 2021 3608.patch | (download)

hw/rdma/vmw/pvrdma_dev_ring.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 pvrdma: fix the ring init error flow (cve-2021-3608)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Bug-Debian: https://bugs.debian.org/990563

Do not unmap uninitialized dma addresses.

Fixes: CVE-2021-3608
ide atapi check logical block address and read size CVE 2020 29443.patch | (download)

hw/ide/atapi.c | 30 24 + 6 - 0 !
1 file changed, 24 insertions(+), 6 deletions(-)

 ide: atapi: check logical block address and read size (cve-2020-29443)
Bug-Debian: https://bugs.debian.org/983575

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.

Fixes: CVE-2020-29443
Reported-by: Wenxiang Qian <leonwxqian@gmail.com>
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
usb limit combined packets to 1 MiB CVE 2021 3527.patch | (download)

hw/usb/combined-packet.c | 4 3 + 1 - 0 !
1 file changed, 3 insertions(+), 1 deletion(-)

 usb: limit combined packets to 1 mib (cve-2021-3527)
Bug-Debian: https://bugs.debian.org/988157

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

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

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-Id: <20210503132915.2335822-6-kraxel@redhat.com>

usb redir avoid dynamic stack allocation CVE 2021 3527.patch | (download)

hw/usb/redirect.c | 6 3 + 3 - 0 !
1 file changed, 3 insertions(+), 3 deletions(-)

 usb/redir: avoid dynamic stack allocation (cve-2021-3527)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Bug-Debian: https://bugs.debian.org/988157

Use autofree heap allocation instead.

Fixes: 4f4321c11ff ("usb: use iovecs in USBPacket")
usbredir fix free call CVE 2021 3682.patch | (download)

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

 usbredir: fix free call
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Bug-Debian: http://bugs.debian.org/991911

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

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/491
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
uas add stream number sanity checks CVE 2021 3713.patch | (download)

hw/usb/dev-uas.c | 11 11 + 0 - 0 !
1 file changed, 11 insertions(+)

 uas: add stream number sanity checks.
Bug-Debian: https://bugs.debian.org/992727
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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

Fixes: CVE-2021-3713
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reported-by: Chen Zhe <chenzhe@huawei.com>
Reported-by: Tan Jingguo <tanjingguo@huawei.com>
virtio net fix use after unmap free for sg CVE 2021 3748.patch | (download)

hw/net/virtio-net.c | 39 32 + 7 - 0 !
1 file changed, 32 insertions(+), 7 deletions(-)

 virtio-net: fix use after unmap/free for sg
Bug-Debian: https://bugs.debian.org/993401

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

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

This addresses CVE-2021-3748.

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

virtio net fix map leaking on error during receive CVE 2022 26353.patch | (download)

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

 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.

Reported-by: Victor Tom <vv474172261@gmail.com>
Cc: qemu-stable@nongnu.org
Fixes: CVE-2022-26353
Fixes: bedd7e93d0196 ("virtio-net: fix use after unmap/free for sg")
ati_2d fix buffer overflow in ati_2d_blt CVE 2021 3638.patch | (download)

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

 hw/display/ati_2d: fix buffer overflow in ati_2d_blt (cve-2021-3638)
Date: Mon,  6 Sep 2021 17:31:03 +0200
Message-Id: <20210906153103.1661195-1-philmd@redhat.com>
Bug-Debian: https://bugs.debian.org/992726

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

Reported-by: Qiang Liu <qiangliu@zju.edu.cn>
Fixes: 584acf34cb0 ("ati-vga: Fix reverse bit blts")
Signed-off-by: Philippe Mathieu-Daud <philmd@redhat.com>

vhost user gpu/fix memory disclosure in virgl_cmd_get_capset_info CVE 2021 3545.patch | (download)

contrib/vhost-user-gpu/virgl.c | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

 vhost-user-gpu: fix memory disclosure in virgl_cmd_get_capset_info (cve-2021-3545)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Bug-Debian: https://bugs.debian.org/989042

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

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

Signed-off-by: Li Qiang <liq3ea@163.com>
vhost user gpu/fix resource leak in vg_resource_create_2d CVE 2021 3544.patch | (download)

contrib/vhost-user-gpu/vhost-user-gpu.c | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

 vhost-user-gpu: fix resource leak in 'vg_resource_create_2d' (cve-2021-3544)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Bug-Debian: https://bugs.debian.org/989042

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

Fixes: CVE-2021-3544
Reported-by: Li Qiang <liq3ea@163.com>
vhost user gpu/fix memory leak in vg_resource_attach_backing CVE 2021 3544.patch | (download)

contrib/vhost-user-gpu/vhost-user-gpu.c | 5 5 + 0 - 0 !
1 file changed, 5 insertions(+)

 vhost-user-gpu: fix memory leak in vg_resource_attach_backing (cve-2021-3544)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Bug-Debian: https://bugs.debian.org/989042

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

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

Signed-off-by: Li Qiang <liq3ea@163.com>
vhost user gpu/fix memory leak while calling vg_resource_unref CVE 2021 3544.patch | (download)

contrib/vhost-user-gpu/vhost-user-gpu.c | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

 vhost-user-gpu: fix memory leak while calling 'vg_resource_unref' (cve-2021-3544)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Bug-Debian: https://bugs.debian.org/989042

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

	vg_resource_create_2d
	vg_resource_attach_backing
	vg_resource_unref

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

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

vhost user gpu/fix memory leak in virgl_cmd_resource_unref CVE 2021 3544.patch | (download)

contrib/vhost-user-gpu/virgl.c | 7 7 + 0 - 0 !
1 file changed, 7 insertions(+)

 vhost-user-gpu: fix memory leak in 'virgl_cmd_resource_unref' (cve-2021-3544)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Bug-Debian: https://bugs.debian.org/989042

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

	virgl_cmd_create_resource_2d
	virgl_resource_attach_backing
	virgl_cmd_resource_unref

This patch fixes this.

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

Signed-off-by: Li Qiang <liq3ea@163.com>
vhost user gpu/fix memory leak in virgl_resource_attach_backing CVE 2021 3544.patch | (download)

contrib/vhost-user-gpu/virgl.c | 5 4 + 1 - 0 !
1 file changed, 4 insertions(+), 1 deletion(-)

 vhost-user-gpu: fix memory leak in 'virgl_resource_attach_backing' (cve-2021-3544)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Bug-Debian: https://bugs.debian.org/989042

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

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

Signed-off-by: Li Qiang <liq3ea@163.com>