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