QEMU's vhost inflight migration VMState handling uses a uint64t field for the destination buffer size, while the VMSVBUFFER load path reads the field as a signed int32t. On little-endian hosts, a crafted incoming migration state with bit 31 set can cause the negative value to be converted to a very large sizet. QEMU may then copy migration-stream data beyond the mmap-backed destination inflight region, causing a destination QEMU process crash or memory corruption. Exploitation requires control of the migration producer or write access to the migration channel and a configuration using vhost inflight migration.

Acknowledgments: Seungjung Kim (Kyonggi University)

A heap buffer over-read was found in block/vmdk.c. A crafted VMDK file can make qemu-img (or qemu with vmdk disk) read past an allocated buffer, potentially leading to a 12-byte information leak or denial of service.

Patch: https://lore.kernel.org/qemu-devel/CAJ9qJssSwxkmEVethg57-Ph6maEfButSaV-r07ma9x1sp6wYg@mail.gmail.com/

Credit: Halil Oktay (oblivionsage)

A flaw was found in QEMU in the uefi-vars virtual device. When the guest writes to register UEFIVARSREGBUFFERSIZE, the .write callback uefivarswrite is invoked. The function allocates a heap buffer without zeroing the memory, leaving the buffer filled with residual data from prior allocations. When the guest later reads from register UEFIVARSREGPIOBUFFERTRANSFER, the .read callback uefivarsread returns leftover metadata or other sensitive process memory from the previously allocated buffer, leading to an information disclosure vulnerability.

A flaw was found in QEMU in the virtio-scsi, virtio-blk and virtio-crypto devices. The size for virtqueuepush as set in virtioscsicompletereq / virtioblkreqcomplete / viritocryptoreqcomplete could be larger than the true size of the data which has been sent to guest.

Once virtqueuepush() finally calls dmamemoryunmap to ummap the iniov, it may call the addressspacewrite function to write back the data. Some uninitialized data may exist in the bounce.buffer, leading to an information leak.

Upstream fix: https://gitlab.com/qemu-project/qemu/-/commit/637b0aa139565cb82a7b9269e62214f87082635c

A flaw was found in QEMU in the virtio-scsi, virtio-blk and virtio-crypto devices. The size for virtqueuepush as set in virtioscsicompletereq / virtioblkreqcomplete / viritocryptoreqcomplete could be larger than the true size of the data which has been sent to guest.

Once virtqueuepush() finally calls dmamemoryunmap to ummap the iniov, it may call the addressspacewrite function to write back the data. Some uninitialized data may exist in the bounce.buffer, leading to an information leak.

Upstream fix: https://gitlab.com/qemu-project/qemu/-/commit/637b0aa139565cb82a7b9269e62214f87082635c

An assertion failure was found in QEMU in the usbepget() function in hw/net/core.c. The TD PID needs to be either USBTOKENIN or USBTOKENOUT in usbepget, but in the caller uhcihandletd it may be USBTOKENSETUP.

An unprivileged guest user may be able to reach the assertion. Users are not directly able to craft URBs, however as a user, one might be able to find a kernel path that would send a TD with PID USBTOKENSETUP to QEMU (which is called USBPIDSETUP in Linux). For instance in the Linux Kernel, uhcisubmitcontrol in drivers/usb/host/uhci-q.c:789 does link a USBPIDSETUP TD to the URB.

Upstream issue: https://gitlab.com/qemu-project/qemu/-/issues/2548

QEMU through 8.0.0 could trigger a division by zero in scsidiskreset in hw/scsi/scsi-disk.c because scsidiskemulatemodeselect does not prevent s->qdev.blocksize from being 256. This stops QEMU and the guest immediately.

https://gitlab.com/thuth/qemu/-/commit/3f91104484e5bf55b56d7e1b039a4a5a17d0c1a7 https://gitlab.com/qemu-project/qemu/-/issues/1813

A flaw was found in the vhost-vsock device of QEMU. In case of error, an invalid element was not detached from the virtqueue before freeing its memory, leading to memory leakage and other unexpected results. Affected QEMU versions <= 6.2.0.

A flaw was found in the vhost-vsock device of QEMU. In case of error, vhostvsockcommonsendtransportreset() did not detach the invalid element from the virtqueue before freeing its memory, leading to memory leakage or other unexpected results.

Upstream commit: https://gitlab.com/qemu-project/qemu/-/commit/8d1b247f3748ac4078524130c6d7ae42b6140aaf

A NULL pointer dereference was found in the ACPI code of QEMU. The flaw lies in hw/acpi/pcihp.c in pciwrite() where the bus pointer is used without checking if it's NULL, probably because an invalid selector was supplied. A malicious privileged user within the guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition.

Upstream issue: https://gitlab.com/qemu-project/qemu/-/issues/770

Upstream patch: https://lists.nongnu.org/archive/html/qemu-devel/2021-12/msg01491.html

A deadlock issue was found in the AHCI controller device (ich9-ahci) of QEMU while handling a host-to-device Register FIS (Frame Information Structure) packet from the guest. The bug is triggered on a software reset (ahciresetport) in the handleregh2dfis() function [1]. A privileged user inside the guest could use this flaw to hang the QEMU process on the host, resulting in a denial of service condition.

[1] https://github.com/qemu/qemu/blob/v6.1.0-rc4/hw/ide/ahci.c#L1215

A KVM guest can crash qemu-kvm (likely with a stack overflow) when the guest has been started with the intel-hda device. According to the upstream ticket, the crash is due to a stack overflow.

References: https://bugs.launchpad.net/qemu/+bug/1907497 https://gitlab.com/qemu-project/qemu/-/issues/542

An information disclosure vulnerability was found in the virtio vhost-user GPU device (vhost-user-gpu) of QEMU. The flaw exists in virglcmdgetcapsetinfo() in contrib/vhost-user-gpu/virgl.c and could occur due to the read of uninitialized memory. A malicious guest could exploit this issue to leak memory from the host.

Patch series: https://lists.nongnu.org/archive/html/qemu-devel/2021-05/msg04536.html

Memory disclosure in virglcmdgetcapsetinfo() in virgl.c: https://lists.nongnu.org/archive/html/qemu-devel/2021-05/msg04539.html

Several memory leaks were found in the virtio vhost-user GPU device (vhost-user-gpu) of QEMU. They exist in contrib/vhost-user-gpu/vhost-user-gpu.c and contrib/vhost-user-gpu/virgl.c due to improper release of memory (i.e., free) after effective lifetime. For more information, please refer to the upstream patchset below.

Patch series: https://lists.nongnu.org/archive/html/qemu-devel/2021-05/msg04536.html

Memory leak in vgresourcecreate2d() in vhost-user-gpu.c : https://lists.nongnu.org/archive/html/qemu-devel/2021-05/msg04541.html

Memory leak in vgresourceattachbacking() in vhost-user-gpu.c: https://lists.nongnu.org/archive/html/qemu-devel/2021-05/msg04534.html

Memory leak in vgresourcedestroy() in vhost-user-gpu.c: https://lists.nongnu.org/archive/html/qemu-devel/2021-05/msg04538.html

Memory leak in virglcmdresourceunref() in virgl.c: https://lists.nongnu.org/archive/html/qemu-devel/2021-05/msg04540.html

Memory leak in virglresourceattachbacking() in virgl.c: https://lists.nongnu.org/archive/html/qemu-devel/2021-05/msg04537.html

A flaw was found in the USB redirection support (usb-redir) of QEMU. More specifically, 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. The combined size of the bulk sending is used in usbredirhandlebulkdata() to dynamically allocate a variable length array (VLA) on the stack. Since the total size is not bounded, a malicious guest could be able to influence the array length and cause the QEMU process to perform an excessive allocation on the stack, resulting in a denial of service.

A heap buffer overflow was found in the floppy disk emulator of QEMU up to 6.0.0 (including). It could occur in fdctrltransferhandler() in hw/block/fdc.c while processing DMA read data transfers from the floppy drive to the guest system. A privileged guest user could use this flaw to crash the QEMU process on the host resulting in DoS scenario, or potential information leakage from the host memory.

A flaw was found in the virtio-fs shared file system daemon (virtiofsd) of QEMU. The new 'xattrmap' option may cause the 'security.capability' xattr in the guest to not drop on file write, potentially leading to a modified, privileged executable in the guest. In rare circumstances, this flaw could be used by a malicious user to elevate their privileges within the guest.

A potential stack overflow via infinite loop issue was found in various NIC emulators of QEMU. The said issue occurs in loopback mode of a NIC wherein reentrant DMA checks get bypassed. A guest user/process may use this flaw to consume cpu cycles or crash the QEMU process on the host resulting in DoS scenario.

Upstream patch: --------------- -> https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg07431.html

A stack overflow via infinite recursion issue was found in the eepro100 i8255x device emulator of QEMU. It could occur while processing controller commands due to DMA re-entrancy issue. A guest user/process may use this flaw to consume cpu cycles or crash the QEMU process on the host resulting in DoS scenario.

Upstream patch: --------------- -> https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg06098.html

An infinite loop issue was found in the e1000 NIC emulator of the QEMU. It occurs while processing transmit (tx) descriptors in processtxdesc, if various descriptor fields are initialised with invalid values. A guest may use this flaw to consume cpu cycles on the host resulting in DoS scenario.

Upstream patch: --------------- -> https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg03595.html

An out-of-bound heap buffer access via an interrupt ID field resulting from undefined behaviour. 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.

It requires unusual kernel start-up with 'kernel-irqchip=off'.

This issue does not affect default configuration ie. kernel-irqchip=on.

Upstream patch: --------------- -> https://gitlab.com/qemu-project/qemu/-/commit/edfe2eb4360cde4ed5d95bda7777edcb3510f76a

A use-after-free flaw was found in the MegaRAID emulator of QEMU. This issue occurs while processing SCSI I/O requests in the case of an error mptsasfreerequest() that does not dequeue the request object 'req' from a pending requests queue. This flaw allows a privileged guest user to crash the QEMU process on the host, resulting in a denial of service. Versions between 2.10.0 and 5.2.0 are potentially affected.

An integer overflow issue was found in the vmxnet3 NIC emulator of the QEMU. It may occur if a guest was to supply invalid values for rx/tx queue size or other NIC parameters. A privileged guest user may use this flaw to crash the QEMU process on the host resulting in DoS scenario.

Upstream patch: --------------- -> https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg07935.html

An integer overflow issue was found in the vmxnet3 NIC emulator of the QEMU for versions up to v5.2.0. It may occur if a guest was to supply invalid values for rx/tx queue size or other NIC parameters. A privileged guest user may use this flaw to crash the QEMU process on the host resulting in DoS scenario.

A NULL pointer dereference issue was found in the Floopy disk emulator of QEMU. It could occur while processing read/write ioport commands, if the selected Floopy drive is not initialised with a block device. A privileged guest user could use this flaw to crash the QEMU process on the host resulting in DoS scenario.

Upstream patch: --------------- -> https://lists.nongnu.org/archive/html/qemu-devel/2021-01/msg05986.html

A NULL pointer dereference issue was found in the megasas-gen2 SCSI host bus adapter emulation of QEMU. It could occur in the megasascommandcancelled() callback function in hw/scsi/megasas.c while dropping a SCSI request. A privileged guest user may exploit this issue to crash the QEMU process on the host, resulting in a denial of service condition.

An infinite loop flaw was found in the USB xHCI controller emulation of QEMU while computing the length of the Transfer Request Block (TRB) Ring. This flaw allows a privileged guest user to hang the QEMU process on the host, resulting in a denial of service.

An out-of-bounds access issue was found in the SLiRP user networking implementation of QEMU. It could occur while processing ARP/NCSI packets, if the packet length was shorter than required to accommodate respective protocol headers and payload. A privileged guest user may use this flaw to potentially leak host information bytes.

Upstream patch: --------------- -> https://lists.freedesktop.org/archives/slirp/2020-November/000115.html

An out-of-bounds read access issue was found in the ATAPI Emulator of QEMU. It occurs while processing ATAPI read command if logical block address(LBA) is set an invalid value. A guest user may use this flaw to crash the QEMU process on the host resulting in DoS scenario.

Upstream patch: --------------- -> https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg04255.html -> https://git.qemu.org/?p=qemu.git;a=commit;h=813212288970c39b1800f63e83ac6e96588095c6

A divide-by-zero issue was found in QEMU in the dwc-hsotg (dwc2) USB host controller emulation. More specifically, HCCHARMPS was read from a device register and later used as divisor without performing any sanity check. This could allow a malicious/buggy guest to crash the QEMU process on the host, resulting in a denial of service.

Upstream fix: https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg04263.html