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 filePatch | File delta | Description |
---|---|---|
use fixed data path.patch | (download) |
softmmu/vl.c |
2 2 + 0 - 0 ! |
use fixed data dir instead of determining it at runtime |
microvm default machine type.patch | (download) |
hw/i386/microvm.c |
3 3 + 0 - 0 ! |
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 ! |
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 ! |
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 ! |
[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 ! |
--- |
openbios use source_date_epoch in makefile.patch | (download) |
roms/openbios/Makefile.target |
4 2 + 2 - 0 ! |
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 ! |
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 ! |
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 ! |
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 ! |
various spelling fixes |
pc bios descriptors fix paths in json files.patch | (download) |
pc-bios/descriptors/meson.build |
3 1 + 2 - 0 ! |
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 ! |
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 ! |
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 ! |
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 ! |
[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 ! |
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 ! |
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 ! |
[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 ! |
[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 ! |
[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 ! |
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 ! |
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 ! |
[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 ! |
[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 ! |
[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 ! |
[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 ! |
[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 ! |
[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 ! |
[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 ! |
[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 ! |
[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 ! |
[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 ! |
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 ! |
[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 ! |
[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 ! |
[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 ! |
[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 ! |
[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 ! |
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 ! |
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 ! |
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 ! |
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 ! |
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 ! |
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 ! |
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 ! |
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 ! |
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 ! |
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 ! |
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 ! |
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 ! |
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 ! |
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 ! |
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 ! |
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 ! |
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 ! |
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> |