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

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

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 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 flaw was found in the QEMU Guest Agent (qga). A local unprivileged user can exploit a vulnerability in the guest-ssh-add-authorized-keys command handler by manipulating symbolic links. This can occur either through a deterministic directory-symlink bypass or a Time-of-Check to Time-of-Use (TOCTOU) file-symlink race. Successful exploitation allows the attacker to gain ownership of arbitrary root-owned files or directories, leading to root access. This vulnerability requires an external management layer (e.g., libvirt) to trigger the affected code path.

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)

When qmpguestsshaddauthorizedkeys adds an SSH key for an existing local user, the agent (running as root) decides whether to create the user's .ssh directory with a symlink-following directory test, and then writes and chowns the authorizedkeys file using a plain chown (not lchown). A local unprivileged user who owns their home directory can pre-stage their .ssh directory (or the authorizedkeys file) as a symbolic link so that, when the host or operator triggers a key add for that user, the root agent follows the link and transfers ownership of an arbitrary root-owned file or directory to the unprivileged user, who can then rewrite it to obtain root.

Patch: https://patchew.org/QEMU/20260709105707.91209-1-kkostiuk@redhat.com/

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.

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

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.

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

In the Linux kernel, the following vulnerability has been resolved:

KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling

Hyunwoo Kim reports some really bad races should the following situation occur:

- LPI-I is pending in vcpu-B's AP list - vcpu-A writes to vcpu-B's RD to disable its LPIs - vcpu-C moves I from B to C

If the last two race nicely enough, vgicpruneaplist() can drop the irq and AP list locks, reacquire them, and in the interval the irq has been freed. UAF follows.

The fix is two-fold:

- Before dropping the irq and aplist locks, take a reference on the irq

- Do not try to handle migration of the pending bit: there is no expectation that this state is retained, as per the architecture

With that, we're sure that the interrupt is still around, and we safely remove it from the AP list as it has no target at this stage (unless another interrupt fires, but that's another story).

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 vulnerability in the lsi53c895a device affects the latest version of qemu. A DMA-MMIO reentrancy problem may lead to memory corruption bugs like stack overflow or use-after-free.

A flaw was found in the QEMU disk image utility (qemu-img) 'info' command. A specially crafted image file containing a json:{} value describing block devices in QMP could cause the qemu-img process on the host to consume large amounts of memory or CPU time, leading to denial of service or read/write to an existing external file.

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.

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.

hw/display/cirrusvgarop.h in QEMU (aka Quick Emulator) allows local guest OS privileged users to cause a denial of service (out-of-bounds read and QEMU process crash) via vectors related to copying VGA data via the cirrusbitbltropfwdtransp and cirrusbitbltropfwd functions.

A use-after-free issue was found in the SLiRP networking implementation of the QEMU emulator. It occurs in ipreass() routine while reassembling incoming packets, if the first fragment is bigger than the m->mdat[] buffer.

A user/process could use this flaw to crash the Qemu process on the host resulting in DoS.

Upstream patch: --------------- -> https://gitlab.freedesktop.org/slirp/libslirp/commit/c59279437eda91841b9d26079c70b8a540d41204

A use-after-free issue was found in the SLiRP networking implementation of the QEMU emulator. It occurs in ipreass() routine while reassembling incoming packets, if the first fragment is bigger than the m->mdat[] buffer.

A user/process could use this flaw to crash the Qemu process on the host resulting in DoS.

Upstream patch: --------------- -> https://gitlab.freedesktop.org/slirp/libslirp/commit/c59279437eda91841b9d26079c70b8a540d41204

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.

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.

An issue was discovered in QEMU 7.1.0 through 8.2.1. registervfs in hw/pci/pciesriov.c does not set NumVFs to PCISRIOVTOTALVF, and thus interaction with hw/nvme/ctrl.c is mishandled.

An issue was discovered in QEMU 7.1.0 through 8.2.1. registervfs in hw/pci/pciesriov.c mishandles the situation where a guest writes NumVFs greater than TotalVFs, leading to a buffer overflow in VF implementations.

Last updated 13 August 2024