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

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 use-after-free issue was found in the INTEL 82574 NIC (e1000e) emulator of the QEMU. It could while sending packets if the guest user set the packet data address to e1000e's MMIO address. A guest user/process could 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/2020-07/msg06147.html

Reference: ---------- -> https://bugs.launchpad.net/qemu/+bug/1886362

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.

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.

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

An assertion failure flaw was found in QEMU in the network packet processing component. This issue affects the "e1000e" and "vmxnet3" network devices. This flaw allows a malicious guest user or process to abort the QEMU process on the host, resulting in a denial of service.

In QEMU 4.2.0, a MemoryRegionOps object may lack read/write callback methods, leading to a NULL pointer dereference.

Last updated 25 August 2025

addressspacemap in exec.c in QEMU 4.2.0 can trigger a NULL pointer dereference related to BounceBuffer.

In QEMU 5.0.0 and earlier, megasaslookupframe in hw/scsi/megasas.c h ...

In QEMU 5.0.0 and earlier, es1370transferaudio in hw/audio/es1370.c ...

An out-of-bounds read/write vulnerability was found in function Sm5012doperation() in hw/display/sm501.c. The OOB flaw is caused by an integer overflow in COPYAREA when the rtl parameter is set to 1, and either srcy or srcx is less than operationheight. Please refer to the following duplicate bug for further details: https://bugzilla.redhat.com/showbug.cgi?id=1786026.

Upstream fix: https://git.qemu.org/?p=qemu.git;a=commit;h=b15a22bbcbe6a78dc3d88fe3134985e4cdd87de4

A heap buffer overflow flaw was found in the iSCSI support of QEMU. This flaw could lead to an out-of-bounds read access and possible information disclosure from the QEMU process memory to a malicious guest. The highest threat from this vulnerability is to data confidentiality.

An integer overflow was found in QEMU 4.0.1 through 4.2.0 in the way it implemented ATI VGA emulation. This flaw occurs in the ati2dblt() routine in hw/display/ati-2d.c while handling MMIO write operations through the atimmwrite() callback. A malicious guest could abuse this flaw to crash the QEMU process, resulting in a denial of service.

hw/ppc/spapr.c in QEMU through 3.1.0 allows Information Exposure because the hypervisor shares the /proc/device-tree/system-id and /proc/device-tree/model system attributes with a guest.

A memory leakage flaw was found in the way the VNC display driver of QEMU handled the connection disconnect when ZRLE and Tight encoding are enabled. Two VncState objects are created, and one allocates memory for the Zlib's data object. This allocated memory is not freed upon disconnection, resulting in a memory leak. An attacker able to connect to the VNC server could use this flaw to leak host memory, leading to a potential denial of service.

In QEMU 1:4.1-1, 1:2.1+dfsg-12+deb8u6, 1:2.8+dfsg-6+deb9u8, 1:3.1+dfsg-8~deb10u1, 1:3.1+dfsg-8+deb10u2, and 1:2.1+dfsg-12+deb8u12 (fixed), when executing script in lsiexecutescript(), the LSI scsi adapter emulator advances 's->dsp' index to read next opcode. This can lead to an infinite loop if the next opcode is empty. Move the existing loop exit after 10k iterations so that it covers no-op opcodes as well.

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 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 0.8.2 allows local users to halt a virtual machine by executing the icebp instruction.

QEMU 0.8.2 allows local users to crash a virtual machine via the divisor operand to the aam instruction, as demonstrated by "aam 0x0," which triggers a divide-by-zero error.

QEMU 0.9.0 does not properly handle changes to removable media, which allows guest OS users to read arbitrary files on the host OS by using the diskformat: parameter in the -usbdevice option to modify the disk-image header to identify a different format, a related issue to CVE-2008-2004.

The changeprocessuid function in os-posix.c in Qemu 0.14.0 and earlier does not properly drop group privileges when the -runas option is used, which allows local guest users to access restricted files on the host.

A dangling pointer access flaw was found in the way qemu handled hot-unplugging virtio devices. This flaw was introduced by virtio refactoring and exists in the virtio-pci implementation. When the virtio-blk-pci device is deleted, the virtio-blk-device is removed first (removal is done in post-order). Later, the virtio-blk-device is accessed again, but proxy->vdev->vq is no longer valid (a dangling pointer) and kvmsetioeventfdpio fails.

A privileged guest user could use this flaw to crash the qemu process on the host system, causing a denial of service to it and any other running virtual machines.

Patches are available at http://thread.gmane.org/gmane.comp.emulators.qemu/234440

Acknowledgements:

This issue was discovered by Sibiao Luo of Red Hat.