A type mismatch vulnerability was found in QEMU's vhost inflight migration VMState handling. The destination buffer size is stored as a uint64t but read by the VMSVBUFFER load path as a signed int32t. On little-endian hosts, a crafted incoming migration state with bit 31 set causes the value to be interpreted as negative and then implicitly converted to a very large sizet, leading qemugetbuffer() to copy migration-stream data beyond the bounds of the mmap-backed inflight region.
This can result in a crash of the QEMU process or memory corruption. Exploitation requires control of the migration producer or write access to the migration channel, combined with a destination configured to use vhost inflight migration.
This vulnerability allows local attackers to escalate privileges on affected installations of QEMU. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the implementation of the virtual LSI53C895A SCSI Host Bus Adapter. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the hypervisor.
This vulnerability allows local attackers to escalate privileges on affected installations of QEMU. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the implementation of the virtual LSI53C895A SCSI Host Bus Adapter. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the hypervisor.
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
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 could be used by a privileged user in the guest to crash the QEMU process on the host.
A use-after-free vulnerability was found in the QEMU LSI53C895A SCSI Host Bus Adapter emulation. This issue can lead to a crash or VM escape.
There is an use-after-free vulnerability in QEMU LSI53C895A SCSI Host Bus Adapter emulation, which can lead to VM escape. The crash noticed in this case is an write to freed memory. But given the complexity of the freed structure, multiple primitives like dereferencing function pointers, etc., should be possible.
A flaw was found in QEMU in the Virtio PCI Bindings (hw/virtio/virtio-pci.c). An improper release and use of the irqfd for vector 0 during the boot process leads to a guest triggerable crash via vhostnetstop().
The original patch [1] was found to be incomplete and is currently being reworked upstream [2][3].
[1] https://gitlab.com/qemu-project/qemu/-/commit/fcbb086ae590e910614fe5b8bf76e264f71ef304 [2] https://gitlab.com/qemu-project/qemu/-/issues/2321 [3] https://gitlab.com/qemu-project/qemu/-/issues/2334
An assertion failure issue was found in the updatesctpchecksum() function in hw/net/nettxpkt.c when trying to calculate the checksum of a short-sized fragmented packet. A malicious guest could use this flaw to crash QEMU and cause a denial of service condition.
Upstream issue & patch: https://gitlab.com/qemu-project/qemu/-/issues/2273 https://patchew.org/QEMU/20240410070459.49112-1-philmd@linaro.org/
A heap based buffer overflow was found in the SDHCI device emulation of QEMU. The bug is triggered when both s->datacount and the size of s->fifobuffer are set to 0x200, leading to an out-of-bound access. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition.
Upstream patch: https://patchew.org/QEMU/20240404085549.16987-1-philmd@linaro.org/
oss-fuzz bug: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=58813
This vulnerability allows local attackers to disclose sensitive information on affected installations of QEMU. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the NVMe virtual device. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the hypervisor.
This vulnerability allows local attackers to disclose sensitive information on affected installations of QEMU. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the NVMe virtual device. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the hypervisor.
A stack based buffer overflow was found in the virtio-net device of QEMU. The flaw occurs while copying data to mhdr, a local variable of type virtionethdrmrgrxbuf, when flushing TX in the virtionetflushtx function. If guest features VIRTIONETFHASHREPORT, VIRTIOFVERSION1 and VIRTIONETFMRGRXBUF are enabled, n->guesthdrlen is set to sizeof(struct virtionethdrv1hash), which is bigger than sizeof(virtionethdrmrgrxbuf). This vulnerability could potentially allow a malicious user to overwrite local variables adjacent to mhdr allocated on the stack. Specifically, the outsg variable could be used to read some part of process memory and send it to the wire:
ret = qemusendvpacketasync(qemugetsubqueue(n->nic, queueindex), outsg, outnum, virtionettxcomplete);
QEMU through 8.0.0 could trigger a division by zero in scsidiskreset in hw/scsi/scsi-disk.c because scsidiskemulatemodeselect does not prevent s->qdev.blocksize from being 256. This stops QEMU and the guest immediately.
https://gitlab.com/thuth/qemu/-/commit/3f91104484e5bf55b56d7e1b039a4a5a17d0c1a7 https://gitlab.com/qemu-project/qemu/-/issues/1813
QEMU through 8.0.0 could trigger a division by zero in scsidiskreset in hw/scsi/scsi-disk.c because scsidiskemulatemodeselect does not prevent s->qdev.blocksize from being 256. This stops QEMU and the guest immediately.
DISPUTED An issue was discovered in TCG Accelerator in QEMU 4.2.0, allows local attackers to execute arbitrary code, escalate privileges, and cause a denial of service (DoS). Note: This is disputed as a bug and not a valid security issue by multiple third parties.
The hardware emulation in the ofdpacmdaddl2flood of rocker device model in QEMU, as used in 7.0.0 and earlier, allows remote attackers to crash the host qemu and potentially execute code on the host via execute a malformed program in the guest OS.
QEMU through 8.0.4 accesses a NULL pointer in nvmedirectivereceive in hw/nvme/ctrl.c because there is no check for whether an endurance group is configured before checking whether Flexible Data Placement is enabled.
A heap out of bounds memory read was found in the virtual nvme device in QEMU. An offset provided by guest is not validated by qemu process before computing a host heap pointer, which is used for copying data back to guest. Arbitrary heap memory relative to an allocated buffer can be disclosed.
ZDI security advisory: https://www.zerodayinitiative.com/advisories/ZDI-CAN-21521
Upstream patch: https://lists.nongnu.org/archive/html/qemu-devel/2023-08/msg00516.html
alice wrote: this is a disaster of a security announcement from AMD. nothing is fixed except for epyc. the only workaround anyone really has is the chicken bit, thankfully. Yes, very disappointing. Pure speculation; perhaps they were planning on disclosing at the end of the year with full set of Microcode ready but something we don't know (yet) forced them to disclose early. Who knows.
Very unscientific and limited test but I just compiled qemu 7.2.4 on a gentoo workstation with a Ryzen 7 3700X (Zen 2) running linux kernel 5.15.119. Took 5 min 37s. Rebooted into 5.15.122 with the chicken bit fix (confirmed in dmesg appears to be applied), compiled qemu again, this time it took 5 min 25s. So my initial impression is the chicken bit fix is fine in general but remains to be seen if certain workloads significantly impacted I guess.
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
A flaw was found in the 9p passthrough filesystem (9pfs) implementation in QEMU. The 9pfs server did not prohibit opening special files on the host side, potentially allowing a malicious client to escape from the exported 9p tree by creating and opening a device file in the shared folder.
A flaw was found in the QEMU built-in VNC server while processing ClientCutText messages. A wrong exit condition may lead to an infinite loop when inflating an attacker controlled zlib buffer in the inflatebuffer function. This could allow a remote authenticated client who is able to send a clipboard to the VNC server to trigger a denial of service.
A flaw was found in the QEMU Guest Agent service for Windows. A local unprivileged user may be able to manipulate the QEMU Guest Agent's Windows installer via repair custom actions to elevate their privileges on the system.
An integer overflow and buffer overflow issues were found in the ACPI Error Record Serialization Table (ERST) device of QEMU in the readerstrecord() and writeerstrecord() functions. Both issues may allow the guest to overrun the host buffer allocated for the ERST memory device. A malicious guest could use these flaws to crash the QEMU process on the host.
An out-of-bounds read flaw was found in the QXL display device emulation in QEMU. The qxlphys2virt() function does not check the size of the structure pointed to by the guest physical address, potentially reading past the end of the bar space into adjacent pages. A malicious guest user could use this flaw to crash the QEMU process on the host causing a denial of service condition.
An integer underflow issue was found in the QEMU VNC server while processing ClientCutText messages in the extended format [1]. A malicious client could use this flaw to make QEMU unresponsive by sending a specially crafted payload message, resulting in a denial of service condition.
[1] https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#extended-clipboard-pseudo-encoding