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 flaw was found in QEMU's virtio-blk device. The issue arises because the device does not properly validate the size of input descriptors before writing data. A malicious guest with high privileges could exploit this vulnerability by submitting a malformed virtio-blk SCSI request, leading to an out-of-bounds write in the host heap memory and a potential denial of service (DoS) for the QEMU process.
QEMU's virtio-blk device can write past the end of a heap-allocated MMIO bounce buffer while handling a crafted VIRTIOBLKTSCSICMD request. A malicious guest that can program virtio-blk request descriptors can make the second-to-last writable input descriptor point to an MMIO guest physical address with a length of only 1 byte. QEMU maps that descriptor through an exact-size heap bounce buffer, then virtioblkhandlescsi() writes the 4-byte virtioscsiinhdr.errors field without first checking that the descriptor is large enough. A malicious guest can cause an out-of-bounds host heap write in the QEMU process by submitting a malformed virtio-blk SCSI request.
This vulnerability allows local attackers to escalate privileges on affected installations of QEMU. An attacker must first obtain the ability to execute low-privileged code on the target guest system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 8.8. The following CVEs are assigned: CVE-2026-3886.
This vulnerability allows local attackers to escalate privileges on affected installations of QEMU. An attacker must first obtain the ability to execute low-privileged code on the target guest system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 8.8. The following CVEs are assigned: CVE-2026-3886.
v12-security have disclosed "QEMUtiny" [0]. Quoting their disclosure: QEMUtiny is a memory corruption vulnerability in QEMU's implementation of CXL Type-3 device emulation, reported against QEMU master 007b29752e and confirmed working against 5e61afe (May 11, 2026).
QEMUtiny was discovered autonomously with V12 by Aaron Esau of the V12 security team.
The PoC chains two CXL mailbox bugs in hw/cxl/cxl-mailbox-utils.c: an out-of-bounds read in GETLOG, followed by an out-of-bounds write in SETFEATURE.
OOB read: cmdlogsgetlog() treats the CEL log offset as an array index in the memmove() source expression even though the CXL mailbox offset is in bytes.
OOB write: cmdfeaturessetfeature() accepts byte offsets into several small feature write-attribute structures without checking that offset + bytestocopy stays inside the selected structure.
We reported the bugs upstream. Maintainers state CXL support is currently for at non-virtualization use cases, so we feel comfortable release the PoC publicly.
The included poc.c is a working exploit that drives the emulated CXL mailbox from the guest through the device BAR. It depends on offsets for the specific QEMU build and host libc layout. The exploit can be weaponized to work reliably across many QEMU versions using the OOB read to scan memory. However this is out of scope for this PoC. See [1] for PoC code. ...
Affected Versions
The full QEMUtiny chain uses two bugs.
OOB read: the vulnerable GETLOG path was introduced by 056172691b (hw/cxl/device: Add log commands (8.2.9.4) + CEL), first released in QEMU v7.1.0.
OOB write: the vulnerable PPR and memory sparing SETFEATURE paths were introduced by 5e5a86bab8 and da5cafdc4d, released in QEMU v11.0.0. [0] https://github.com/v12-security/pocs/tree/main/qemu [1] https://github.com/v12-security/pocs/blob/main/qemu/poc.c
-- Brett Sheffield (he/him)
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.
If cpuphysicalmemorymap() returns a length shorter than the one that was passed into the function, writing the full outlen bytes causes an access beyond the memory allocated to the guest; or in the case of the MMIO bounce buffer, an out-of-bounds access in a heap-allocated object.
Upstream fix: https://gitlab.com/qemu-project/qemu/-/commit/4f28b87fdd24df2049626106b7c24d0180952115
A flaw was found in QEMU. When reading input audio in the virtio-snd device input callback, the virtiosndpcmincb function did not check whether the iov could fit the data buffer, potentially leading to a heap out-of-bounds write. This issue exists due to an incomplete fix for CVE-2024-7730.
A flaw was found in QEMU. When reading input audio in the virtio-snd device input callback, the virtiosndpcmincb function did not check whether the iov could fit the data buffer, potentially leading to a heap out-of-bounds write. This issue exists due to an incomplete fix for CVE-2024-7730.
Original issue: https://gitlab.com/qemu-project/qemu/-/issues/2427
Upstream patch series: https://lore.kernel.org/qemu-devel/20260220-virtio-snd-series-v1-0-207c4f7200a2@linaro.org/
QEMU fix commits: https://gitlab.com/qemu-project/qemu/-/commit/bcb53328aa70023f1405fade4e253e7f77567261 https://gitlab.com/qemu-project/qemu/-/commit/7994203bb1b83a6604f3ab00fe9598909bb66164
An integer overflow vulnerability was found in the virtio-snd device via PCMINFO requests from the guest. A malicious guest can provide out-of-bounds stream counts, potentially leading to unbounded memory allocation on the host and a denial of service condition.
Upstream patch series: https://lore.kernel.org/qemu-devel/20260220-virtio-snd-series-v1-0-207c4f7200a2@linaro.org/
QEMU fix commit: https://gitlab.com/qemu-project/qemu/-/commit/61679d7dcfa2dffc8fb115aa19b09e0e7cf5ea5c
A flaw was found in QEMU. A specially crafted VMDK image could trigger an out-of-bounds read vulnerability, potentially leading to a 12-byte leak of sensitive information or a denial of service condition (DoS).
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)
An off-by-one error was found in QEMU's KVM Xen guest support. A malicious guest could use this flaw to trigger out-of-bounds heap accesses in the QEMU process via the emulated Xen physdev hypercall interface, leading to a denial of service or potential memory corruption.
An off-by-one error was found in QEMU's KVM Xen guest support. A malicious guest could use this flaw to trigger out-of-bounds heap accesses in the QEMU process via the emulated Xen physdev hypercall interface, leading to a denial of service or potential memory corruption.
Patch: https://lore.kernel.org/qemu-devel/13FE03BE60EA78D6+20260109023548.4047-1-vr@darknavy.com/
Credit: DARKNAVY (@DarkNavyOrg)
A flaw was found in the virtio-crypto device of QEMU. A malicious guest operating system can exploit a missing length limit in the AKCIPHER path, leading to uncontrolled memory allocation. This can result in a denial of service (DoS) on the host system by causing the QEMU process to terminate unexpectedly.
A flaw was found in the virtio-crypto device of QEMU. The symmetric path enforces a length limit using conf.maxsize, but the AKCIPHER path does not impose any bound. This could allow a malicious guest to trigger a memory exhaustion condition, potentially resulting in a denial of service (DoS) by aborting the QEMU process on the host.
Upstream patch: https://lore.kernel.org/qemu-devel/20251221024321.143196-1-zhenwei.pi@linux.dev/
A stack-based buffer overflow was found in the QEMU e1000 network device. The code for padding short frames was dropped from individual network devices and moved to the net core code. The issue stems from the device's receive code still being able to process a short frame in loopback mode. This could lead to a buffer overrun in the e1000receiveiov() function via the loopback code path. A malicious guest user could use this vulnerability to crash the QEMU process on the host, resulting in a denial of service.
A stack-based buffer overflow was found in the QEMU e1000 network device. The code for padding short frames was dropped from individual network devices and moved to the net core code. The issue stems from the device's receive code still being able to process a short frame in loopback mode. This could lead to a buffer overrun in the e1000receiveiov() function via the loopback code path. A malicious guest user could use this vulnerability to crash the QEMU process on the host, resulting in a denial of service.
Upstream issue: https://gitlab.com/qemu-project/qemu/-/issues/3043
Patch: https://lore.kernel.org/qemu-devel/20251028160042.3321933-1-peter.maydell@linaro.org/T/#u
A flaw was found in QEMU. If the QIOChannelWebsock object is freed while it is waiting to complete a handshake, a GSource is leaked. This can lead to the callback firing later on and triggering a use-after-free in the use of the channel. This can be abused by a malicious client with network access to the VNC WebSocket port to cause a denial of service during the WebSocket handshake prior to the VNC client authentication.
If the QIOChannelWebsock object is freed while it is waiting to complete a handshake, a GSource is leaked. This can lead to the callback firing later on and triggering a use-after-free in the use of the channel. This flaw can be abused by a malicious client with network access to the VNC WebSocket port to cause a denial of service during the WebSocket handshake prior to the VNC client authentication.
Reported-by: Grant Millar | Cylo <rid>
Upstream patch: https://lists.nongnu.org/archive/html/qemu-devel/2025-10/msg00786.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.
hw/pci/pciesriov.c in QEMU through 10.0.3 mishandles the VF Enable bit write mask, a related issue to CVE-2024-26327.
hw/pci/pciesriov.c in QEMU through 10.0.3 has a migration state inconsistency, a related issue to CVE-2024-26327.
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.
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. An assertion failure was present in the usbepget() function in hw/net/core.c when trying to get the USB endpoint from a USB device. This flaw may allow a malicious unprivileged guest user to crash the QEMU process on the host and cause a denial of service condition.
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 discovered in the qemu code for temporarily exposing an NBD server (used for storage migration and other tasks), where qemu can crash if a client still has a socket open at the time the server is taken offline. Even when qemu is set up to only accept clients with proper TLS credentials, an attacker without the TLS credentials can exploit the flaw by connecting a second socket while a storage migration is ongoing through the intended socket, where the attacker then stalls the NBD handshake to not reach the point of the TLS negotiation, then waiting for the server to go offline. When the NBD server is stopped, closing the attacker's socket can cause qemu to crash, forming a denial of service attack.
A flaw was found in the virtio-net device in QEMU. When enabling the RSS feature on the virtio-net network card, the indirectionstable data within RSS becomes controllable. Setting excessively large values may cause an index out-of-bounds issue, potentially resulting in heap overflow access. This flaw allows a privileged user in the guest to crash the QEMU process on the host.