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.

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 use-after-free vulnerability was found in QEMU's 9pfs subsystem. A race condition between the main thread and a worker thread when processing concurrent Tlcreate and Twalk requests allows a malicious guest user to craft a fid path containing stale heap data, bypassing directory traversal restrictions and escaping the shared directory boundary. This can lead to arbitrary host file read/write and code execution (VM escape) as the QEMU process user.

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.

A flaw was found in QEMU. The VAPIC setup hypercall in hw/i386/vapic.c does not validate that the writable RAM alias remains within the option ROM window. A privileged guest user on a Q35/KVM machine can position this alias over locked SMRAM, bypassing chipset DLCK protection and injecting code into System Management Mode memory.

A flaw was found in QEMU's VAPIC (Virtual Advanced Programmable Interrupt Controller) implementation in hw/i386/vapic.c. The 16-bit VAPIC setup hypercall allows a privileged guest to specify both the base address and size of a high-priority writable RAM alias. QEMU does not validate that this alias remains within the VAPIC option ROM boundaries (0xc0000..0xdffff). A malicious guest administrator can place the alias over 0xa0000..0xbffff, bypassing the Q35 chipset's DLCK-protected SMRAM and modifying memory that executes in System Management Mode. This could allow a privileged guest user to inject arbitrary code into locked SMRAM.

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

Reference: https://gitlab.com/qemu-project/qemu/-/workitems/4206

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

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.

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

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