hw/input/ps2.c in Qemu does not validate 'rptr' and 'count' values during guest migration, leading to out-of-bounds access.
A stack-based buffer overflow vulnerability was found in NBD server implementation in qemu allowing client to request an export name of size up to 4096 bytes, which in fact should be limited to 256 bytes, allowing to cause out-of-bounds stack write in qemu process.
If NBD server requires TLS, the attacker cannot trigger the buffer overflow without first successfully negotiating TLS.
Upstream patch: --------------- -> https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg05045.html
Reference: ---------- -> http://www.openwall.com/lists/oss-security/2017/11/28/8
A potential integer overflow issue was found in the networking back-end of QEMU. It could occur while receiving packets, because it accepted packets with large size value. Such overflow could lead to OOB buffer access issue. A user inside guest could use this flaw to crash the QEMU process resulting in DoS.
A heap buffer overflow issue was found in the loaddevicetree() function of QEMU, which is invoked to load device tree blob at boot time. It occurs due to device tree size manipulation before buffer allocation, which could overflow a signed int type.
A user/process could use this flaw to potentially execute arbitrary code on a host system with privileges of the QEMU process.
Upstream patch: --------------- -> https://git.qemu.org/?p=qemu.git;a=commitdiff;h=da885fe1ee8b4589047484bd7fa05a4905b52b17 -> https://git.qemu.org/?p=qemu.git;a=commitdiff;h=065e6298a75164b4347682b63381dbe752c2b156
Reference: ---------- -> https://www.openwall.com/lists/oss-security/2019/03/27/1
Quick Emulator (Qemu) built with the VirtFS, host directory sharing via Plan 9 File System (9pfs) support, is vulnerable to an improper access control issue. It could occur while accessing files on a shared host directory. A privileged user inside guest could use this flaw to access host file system beyond the shared folder and potentially escalating their privileges on a host.
Last updated 13 August 2024
In the Linux kernel, the following vulnerability has been resolved:
vhost-scsi: protect vq->logused with vq->mutex
The vhost-scsi completion path may access vq->logbase when vq->logused is already set to false.
vhost-thread QEMU-thread
vhostscsicompletecmdwork() -> vhostaddused() -> vhostaddusedn() if (unlikely(vq->logused)) QEMU disables vq->logused via VHOSTSETVRINGADDR. mutexlock(&vq->mutex); vq->logused = false now! mutexunlock(&vq->mutex);
QEMU gfree(vq->logbase) logused() -> logwrite(vq->logbase)
Assuming the VMM is QEMU. The vq->logbase is from QEMU userpace and can be reclaimed via gfree(). As a result, this causes invalid memory writes to QEMU userspace.
The control queue path has the same issue.
Last updated 25 August 2025
Integer overflow in hw/virtio/virtio-crypto.c in QEMU (aka Quick Emulator) allows local guest OS privileged users to cause a denial of service (QEMU process crash) or possibly execute arbitrary code on the host via a crafted virtio-crypto request, which triggers a heap-based buffer overflow.
DISPUTED softmmu/physmem.c in QEMU through 7.0.0 can perform an uninitialized read on the translatefail path, leading to an ioreadx or iowritex crash. NOTE: a third party states that the Non-virtualization Use Case in the qemu.org reference applies here, i.e., "Bugs affecting the non-virtualization use case are not considered security bugs at this time."
Last updated 25 August 2025
The VNC websocket frame decoder in QEMU allows remote attackers to cause a denial of service (memory and CPU consumption) via a large (1) websocket payload or (2) HTTP headers section.
An off-by-one read/write issue was found in the SDHCI device of QEMU. It occurs when reading/writing the Buffer Data Port Register in sdhcireaddataport and sdhciwritedataport, respectively, if datacount == blocksize. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition.
A flaw was found in the USB redirector device (usb-redir) of QEMU. It occurs when dropping packets during a bulk transfer from a SPICE client due to the packet queue being full. More specifically, the usbredirbufferedbulkpacket() function calls bufpalloc() with an invalid pointer that points into the middle of a buffer controlled by the SPICE client. If the packet queue is full, bufpalloc() ends up freeing the same pointer passed as argument. A malicious SPICE client could use this flaw to make QEMU call free() with faked heap chunk metadata, resulting in a crash of QEMU or potential code execution with the privileges of the QEMU process on the host.
Upstream issue: https://gitlab.com/qemu-project/qemu/-/issues/491
Upstream fix: https://gitlab.com/qemu-project/qemu/-/commit/5e796671e6b8d5de4b0b423dce1b3eba144a92c9
The QEMU flaw CVE-2021-3750 (bug 1999073) was declared fixed in Red Hat Enterprise Linux 9.1 via erratum RHSA-2022:7967, released on Nov 15, 2022:
https://access.redhat.com/errata/RHSA-2022:7967
However, the erratum included a version of qemu-kvm that was actually missing the fix for CVE-2021-3750. The CVE-2023-2680 was assigned to this incomplete fix and it is specific to the qemu-kvm packages produced by Red Hat. This issue and CVE-ID is not applicable to any upstream QEMU version or QEMU packages of any other vendor that are not directly based on Red Hat Enterprise Linux packages.
For more information about the original flaw, refer to the CVE page or bug linked above.
A heap buffer overflow issue was found in the way Slirp networking back-end in QEMU processes fragmented packets. It could occur while reassembling the fragmented datagrams of an incoming packet.
A privileged user/process inside guest could use this flaw to crash the QEMU process resulting in DoS OR potentially leverage it to execute arbitrary code on the host with privileges of the QEMU process.
Upstream patch: --------------- -> https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg01012.html
Reference: ---------- -> http://www.openwall.com/lists/oss-security/2018/06/07/1
An out-of-bounds write vulnerability was found in the virtio vhost-user GPU device (vhost-user-gpu) of QEMU in versions up to and including 6.0. The flaw occurs while processing the 'VIRTIOGPUCMDGETCAPSET' command from the guest. It could allow a privileged guest user to crash the QEMU process on the host, resulting in a denial of service condition, or potential code execution with the privileges of the QEMU process.
A DMA reentrancy issue was found in the EHCI controller emulation of QEMU. From https://gitlab.com/qemu-project/qemu/-/issues/541:
""" When EHCI tries to transfer the USB packets, it doesn't check if the Buffer Pointer is overlapped with its MMIO region. So crafted content may be written to the controller's registers and trigger actions like reset, but the device is still transferring packets. """
This flaw could enable a malicious guest to crash QEMU, resulting in a denial of service condition, or potentially execute arbitrary code within the context of the QEMU process on the host. For more information (stack trace, reproducer) see the aforementioned upstream issue.
A heap buffer overflow was found in the virtio-snd device in QEMU. When reading input audio in the virtio-snd input callback, virtiosndpcmincb, the function did not check whether the iov can fit the data buffer. This issue can trigger an out-of-bounds write if the size of the virtio queue element is equal to virtiosndpcmstatus, which makes the available space for audio data zero.
A flaw was found in QEMU. This vulnerability allows a local attacker within a guest virtual machine to write data beyond its allocated memory. This occurs when cpuphysicalmemorymap() returns a shorter length than expected, leading to an out-of-bounds write. Successful exploitation could result in unauthorized access to guest memory or corruption of heap-allocated objects, potentially causing information disclosure, data integrity issues, or a denial of service.
Last updated 25 August 2025
A heap buffer overflow issue was found in the SLiRP networking implementation of the QEMU emulator. It occurs in tcpemu() routine while emulating Identification protocol and copying message data to a socket buffer.
A user/process could use this flaw to crash the Qemu process on the host resulting in DoS or potentially execute arbitrary code with privileges of the QEMU process.
Upstream patch: --------------- -> https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg03132.html
Reference: ---------- -> https://www.openwall.com/lists/oss-security/2019/01/24/5
A flaw was found in the way qemu v1.3.0 and later (virtio-rng) validates addresses when guest accesses the config space of a virtio device. If the virtio device has zero/small sized config space, such as virtio-rng, a privileged guest user could use this flaw to access the matching host's qemu address space and thus increase their privileges on the host.
An OOB heap buffer r/w access issue was found in the NVM Express Controller emulation in QEMU. It could occur in nvmecmbops routines in nvme device. A guest user/process could use this flaw to crash the QEMU process resulting in DoS or potentially run arbitrary code with privileges of the QEMU process.
Qemu 1.1.2+dfsg to 2.1+dfsg suffers from a buffer overrun which could potentially result in arbitrary code execution on the host with the privileges of the QEMU process.
A flaw was found in the way the QEMU-KVM handled erroneous data provided by the guest Linux virtio-net driver. Due deficiency in the implementation of the TSO (TCP segment offloading), the guest's virtio-net driver transmitted improper data to the particular QEMU-KVM process on the host, resulting in its termination. A remote attacker could use this flaw to cause denial of service (guest crash) by sending certain, specially-crafted data to arbitrary open port on the target guest system.
A remote attacker could exploit this to crash guests which use virtio networking on Linux kernels earlier than 2.6.26.
Off-by-one error in monitor.c in Qemu 0.9.1 might make it easier for remote attackers to guess the VNC password, which is limited to seven characters where eight was intended.
Last updated 24 July 2024
It was discovered that the Access Control List (ACL) implemented by qemu-bridge-helper program could be bypassed in particular cases when the bridge interface names are as long as IFNAMSIZ-1, ie 15 characters. If the ACL specified in the /etc/qemu-kvm/bridge.conf file denies access to a bridge interface with a name long IFNAMSIZ-1, but it allows all other interfaces, it is possible for a local attacker to use qemu-bridge-helper to create a tap device and attach it to a denied bridge interface, thus bypassing the ACL. This could be used by the attacker to get access to confidential data transmitted on the bridge.
Upstream patch: --------------- -> https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg00245.html
Reference: ---------- -> https://www.openwall.com/lists/oss-security/2019/07/02/2
A flaw was discovered in 9pfs. Jietao Xiao and his team found that when a local user in the guest tries to write an executable file with SUID or SGID, none of these privileged bits are correctly dropped. As a result, in rare circumstances(exist an executable file owned by root, writable by others, has SUID/SGID bits), this flaw could be used by malicious users in the guest to elevate their privileges within the guest and help a host's local user to elevate privileges on the host.
Upstream issue: https://github.com/v9fs/linux/issues/29