backends/rng: cap request size to avoid oversized allocation
rng_backend_request_entropy() uses the requested size to allocate
a buffer with g_malloc(). With virtio-rng, this size comes from
guest-supplied descriptor lengths. A malicious guest can set a very
large descriptor length, causing QEMU to attempt a multi-gigabyte
allocation and abort.
Cap the allocation to 64 KiB. The virtio-rng queue size is
hardcoded to 8 entries, the EGD backend protocol limits requests
to 255 bytes, the Linux kernel hwrng framework requests at most
SMP_CACHE_BYTES per call (64 bytes on x86_64), and the Windows
viorng driver uses a 4 KiB buffer. The worst legitimate case is
8 x 4 KiB = 32 KiB, so 64 KiB is well above any legitimate use.
Fixes: 14417039653d ("virtio-rng: use virtqueue_get_avail_bytes, fix migration") Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3983 Reported-by: dong ling <dongling226655@outlook.com> Signed-off-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260715141300.2295392-1-lvivier@redhat.com>
Fix a heap-use-after-free in the virtio-rng frontend when a delayed
rng-random backend completion arrives after the virtio-rng device has been
hot-unplugged.
Fixes: CVE-2026-50624
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3917 Reported-by: Jia Jia <physicalmtea@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Signed-off-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260724094931.3005968-1-lvivier@redhat.com>
hw/net/virtio-net: Protect from DMA re-entrancy bugs
Replace qemu_bh_new_guarded() by virtio_bh_new_guarded()
so the bus and device use the same guard. Otherwise the
DMA-reentrancy protection can be bypassed.
This update was missing in CVE-2024-3446 fix.
Fixes: CVE-2026-66022 Cc: qemu-stable@nongnu.org Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Cc: alxndr@bu.edu
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4073 Reported-by: Giovanni Vignone <gio@octane.security> Signed-off-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260723233555.2970619-1-lvivier@redhat.com>
hw/cxl: fix OOB access in cxl_doe_cdat_rsp via entry_handle
cxl_doe_cdat_rsp() takes ent = req->entry_handle (uint16_t, fully
guest-controlled, 0..0xFFFF) and directly indexes cdat->entry[ent]
without checking ent < cdat->entry_len. For a default cxl-type3 with
one volatile memory region, entry_len = 1 + CT3_CDAT_NUM_ENTRIES = 7,
so any entry_handle >= 7 reads past the CDATEntry array into host heap.
The OOB-read base/length are then used in
memcpy(read_mbox + offset, base, len) at cxl_type3.c:298-299, leaking
host heap memory to the guest via PCI_EXP_DOE_RD_DATA_MBOX, and
potentially overflowing the 1 MiB read_mbox heap buffer when the OOB
length field is large.
The same bug exists in the cxl-upstream implementation.
Existing checks do not bound ent: assert(cdat->entry_len) only ensures
the table is loaded; the minimum-length check only guards against a
truncated CDATReq; the entry_handle ternary at line 293 only decides
the next-handle echo, not the current access; pcie_doe_get_obj_len
reads header.length, not entry_handle.
Reproduce: build QEMU with CONFIG_CXL, boot
-M q35,cxl=on -device pxb-cxl,bus_nr=52 ... -device cxl-type3,...
then send a CDATReq with entry_handle=0xFFFF via the DOE mailbox at
config offset 0x190. Under ASAN this reports SEGV in cxl_doe_cdat_rsp
at cxl_type3.c:281.
Fixes: f5ee7413d5 ("hw/mem/cxl-type3: Add CXL CDAT Data Object Exchange") Fixes: 882877fc35 ("hw/pci-bridge/cxl-upstream: Add a CDAT table access DOE") Signed-off-by: Haotian Jiang <jianghaotian.sunday@gmail.com> Cc: qemu-stable@nongnu.org Reviewed-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260713072336.623604-2-jianghaotian.sunday@gmail.com>
hw/virtio/vdpa-dev: pass set_config buffer to vhost backend
vhost_vdpa_device_set_config() receives the updated config buffer, but
forwards s->config to the vhost backend. Since s->config is refreshed by
get_config(), it may contain stale backend state.
Pass the supplied config buffer to vhost_dev_set_config() instead.
Fixes: b430a2bd2303 ("vdpa: add vdpa-dev support") Signed-off-by: GuoHan Zhao <zhaoguohan@kylinos.cn> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260709073225.2341642-1-zhaoguohan@kylinos.cn>
Peter Maydell [Wed, 8 Jul 2026 12:10:11 +0000 (13:10 +0100)]
hw/pci-host/q35.c: Avoid early return in mch_write_config()
In mch_write_config() we return early if has_smm_ranges is false.
This is slightly bug-prone because it leaves the door open to somebody
later adding non-SMM-specific code at the bottom of the function.
This case isn't as bad as the one in realize, because the function is
a lot shorter. But putting the handling of the three SMM specific
ranges into an if() rather than having an early return seems better.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260708121011.1653365-4-peter.maydell@linaro.org>
Peter Maydell [Wed, 8 Jul 2026 12:10:10 +0000 (13:10 +0100)]
hw/pci-host/q35.c: Factor out creation of SMRAM MRs
mch_realize has a large section that deals with initializing the
SMRAM-specific MemoryRegions. Currently we do an early return from
the realize function if mch->has_smm_ranges is false, but this has
the potential for bugs if somebody adds new code at the end of the
function that isn't SMM-specific. Pull the MR init code out into its
own function, so we can do the smm-ranges specific handling in the
realize function in a more obvious way.
This commit shouldn't change behaviour at all.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260708121011.1653365-3-peter.maydell@linaro.org>
Peter Maydell [Wed, 8 Jul 2026 12:10:09 +0000 (13:10 +0100)]
hw/pci-host/q35.c: Always initialize smram-region even if SMM disabled
The MCHPCIState::smram_region looks like it ought to be SMM-specific,
but it isn't, because its behaviour is "alias the PCI address space
into system memory at the SMRAM_C_BASE offset", and it must be
enabled for "hide SMRAM", and disabled for "show SMRAM". If the
SMRAM regions are disabled, we want "hide SMRAM", so we need to
initialize and place this MR. Do this in the minimal way, by moving
the "bail out of realize if has_smm_ranges is false" check down below
the initialization code.
This fixes a bug where disabling SMM causes the VGA screen to be
blank during seabios output, until the OS graphics driver is
initialized. This is most obvious for accelerators which have no SMM
support (e.g. NVMM, HVF, WHPX) as there smm=off is the default, but
you can also see it on KVM and TCG if you explicitly pass smm=off:
qemu-system-x86_64 -machine q35,accel=kvm,smm=off
The early return is bug-prone, so we can refactor the code to clean
it up, but this is the minimal bug fix for backports, and is what
Debian used to work around this:
https://salsa.debian.org/qemu-team/qemu/-/commit/6e0766f0f897dc2b75ab87dd59da0d4639bb37ee
Another proposed fix for this:
https://patchew.org/QEMU/20260413170407.57574-1-mohamed@unpredictable.fr/
also moves an early return in mch_update-smram() and tweaks
mch_update_smram() accordingly. This shouldn't be necessary, because
in the no-SMM case smram_region should always be enabled and we don't
want to allow the guest to make it disabled.
NetBSD bug: https://gnats.NetBSD.org/59721
Cc: qemu-stable@nongnu.org Fixes: b07bf7b7 ("q35: Introduce smm_ranges property for q35-pci-host")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/2608 Reported-by: Kroese (gitlab @kroese) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260708121011.1653365-2-peter.maydell@linaro.org>
Coverity points out one g_malloc0 overflow, but it seems to be a false
positive. Add a check to it regardless to fortify the code, and also add
checks for every other g_malloc0 use.
Resolves: Coverity CID 1547527 Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260420-virtio-fixups-v3-2-07aef1eff9d2@linaro.org>
It must be at least sizeof(virtio_snd_pcm_status).
I haven't verified if it's possible to get an underflow, but coverity
points it out in CID 1547527 so add a check.
Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260420-virtio-fixups-v3-1-07aef1eff9d2@linaro.org>
Currently, within virtio-iommu, handle_command processes the command vq
without any limits on the number of entries processed.
This can easily and repeatedly enable/disable multiple memory regions.
Within the memory code, this causes an accumulation of an
unbounded number of RCU-deferred FlatViews - each of these
is supposed to be freed with call_rcu, but that never happens
because the main thread never returns to the main loop.
Given FlatView is big, it's easy to have this balloon out to multiple
Gigabytes of memory.
Limit the loop defer any remaining work to a timer.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3930 Cc: Eric Auger <eric.auger@redhat.com> Cc: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Reported-by: Jia Jia <physicalmtea@gmail.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <eb46ab360dbe28c29cfa78812a7440dcb7444d59.1784807826.git.mst@redhat.com>
libvduse assumes that vq size (aka vq num) is below VIRTQUEUE_MAX_SIZE
and maps logs large enough based on this assumption.
However, vduse_queue_enable() accepts the vq size returned through
VDUSE_VQ_GET_INFO without validation, so a value above
VIRTQUEUE_MAX_SIZE (1024) overruns the inflight log and causes
out-of-bounds writes in vduse_queue_inflight_get().
According to the virtio spec, vq size can only be reduced, not
increased, so vq size must not exceed the previously configured
max_size, but the kernel vduse module does not validate this for us, and
we should not trust another process to follow the spec.
Validate and reject vq size values above VIRTQUEUE_MAX_SIZE.
Fixes: CVE-2026-61402
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3652 Reported-by: Jia Jia <physicalmtea@gmail.com>
Message-ID: <bf7e71b3139875e5e00fd53970c772d6c90dc2a1.1784888961.git.mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
libvhost-user: fix heap overflow in vu_check_queue_inflights
vu_check_queue_inflights counts inflight descriptors using inflight == 1
but copies entries using inflight != 0. If the inflight field contains
an unexpected non-0/1 value, the function copies more entries than it
allocates and overflows the heap buffer.
Stop the copy pass once resubmit_num reaches the counted inuse value.
Note: the value is not guest-accessible so not a security vulnerability.
Fixes: CVE-2026-63110 Fixes: 5f9ff1eff3 ("libvhost-user: Support tracking inflight I/O in shared memory") Cc: Xie Yongji <xieyongji@bytedance.com> Cc: Stefano Garzarella <sgarzare@redhat.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3974 Reported-by: BB CC <wywwzjj@gmail.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <e2315efc526c0ee918485df4be69e2b26e8b7a73.1784892981.git.mst@redhat.com>
libvhost-user: validate last_batch_head in vu_check_queue_inflights
vu_check_queue_inflights uses last_batch_head from the frontend-controlled
inflight shared memory as an index into desc[] without bounds checking.
A malicious or buggy frontend can set last_batch_head >= desc_num,
causing an out-of-bounds write.
Validate last_batch_head before using it.
Note: the value is not guest-accessible so not a security vulnerability.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3974 Fixes: 5f9ff1eff3 ("libvhost-user: Support tracking inflight I/O in shared memory") Cc: Xie Yongji <xieyongji@bytedance.com> Cc: Stefano Garzarella <sgarzare@redhat.com> Reported-by: BB CC <wywwzjj@gmail.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <8133770c75c9907578dd551f4d468140a0a75cd2.1784892981.git.mst@redhat.com>
virtio_pmem_flush submits fsync requests to the thread pool and stores a
VirtIOPMEM pointer in each request. If device is deleted e.g. by
hot-unplug, once these complete, done_cb can run after
virtio_pmem_unrealize frees the device, causing a use-after-free.
Track in-flight requests and wait in virtio_pmem_unrealize until
their completions finish before tearing the device down.
Fixes: CVE-2026-63323 Fixes: 5f503cd9f3 ("virtio-pmem: add virtio device") Cc: David Hildenbrand <david@kernel.org> Cc: Pankaj Gupta <pagupta@redhat.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3938 Reported-by: Jia Jia <physicalmtea@gmail.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <417b6685f37ce818c660ca3c84945992f5c30dcf.1784894206.git.mst@redhat.com>
scrub_shadow_regions() and vhost_user_add_remove_regions() use
fixed-size stack arrays sized to VHOST_USER_MAX_RAM_SLOTS and index them
with dev->mem->nregions.
nregions is calculated to never overrun these, but let's add an assert
to make sure we don't get a stack overflow if there's a bug.
Fixes: f1aeb14b08 ("Transmit vhost-user memory regions individually")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3910 Cc: Stefano Garzarella <sgarzare@redhat.com> Cc: Raphael Norwitz <raphael.norwitz@nutanix.com> Reported-by: Feifan Qian <bea1e@proton.me> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <48fb8411f67e525872fb19618a886e52b670ab7f.1784896199.git.mst@redhat.com>
virtio_load() attempts to load config_len bytes from the migration
stream. If that's huge (e.g. 4g) this will uselessly spin
beyond the end of the stream for seconds. Not nice.
Check qemu_file_get_error() and bail out early, instead.
Also note that config_len is int32_t but is coerced to unsigned when
used. Switch it to uint32_t to make this clearer.
Fixes: 2f5732e964 ("Allow mismatched virtio config-len") Cc: Dr. David Alan Gilbert <dave@treblig.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3891 Reported-by: Feifan Qian <bea1e@proton.me> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <cfbefa358af5885eb386637216552bfeba5e7bbc.1784898922.git.mst@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org>
virtio: stop migrating num_default, validate vring.num on load
num_default tracks the allocation size of used_elems, set by
virtio_add_queue(). Migrating it via the ringsize subsection is
wrong: a migration stream (malicious or simply from a different
configuration) can inflate num_default so that
virtio_queue_set_num() accepts oversized values, leading to OOB
access on the used_elems array.
It is not even migrated consistently: a configuration with a
smaller num_default could thinkably migrate and work but in the
common case of num == num_default the value is not actually sent.
Stop migrating num_default: make virtio_ringsize_needed() return
false so the subsection is never sent, and use VMSTATE_UNUSED to
consume the field from old streams without applying it. The
destination keeps its local num_default from virtio_add_queue(),
which matches the actual allocation.
Also validate vring.num against num_default when loading the core
virtio state, rejecting streams that supply a queue size larger
than the locally allocated maximum.
Fixes: 46c5d0823d ("virtio: ring sizes vs. reset") Fixes: 50e5ae4dc3 ("migration/virtio: Remove simple .get/.put use") Cc: Cornelia Huck <cohuck@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <3e6a7c403f93acc37af6a6332fdc65049ae218fb.1784894327.git.mst@redhat.com>
virtio: fix queue size validation against allocated maximum
virtio_add_queue() allocates used_elems for num_default entries, but
virtio_queue_set_num() accepts larger guest-supplied queue sizes up to
VIRTQUEUE_MAX_SIZE. With VIRTIO_F_IN_ORDER, this lets the guest drive
used_elems accesses past the allocation and cause out-of-bounds reads
and writes.
Reject queue sizes larger than num_default in virtio_queue_set_num()
and mark the device broken.
Fixes: e63c0ba1bc ("virtio: Add support for guest setting of queue size") Fixes: CVE-2026-50626 Cc: Peter Maydell <peter.maydell@linaro.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3882
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3921
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3923
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3613 Reported-by: huntr bubble <bubblehuntr@gmail.com> Reported-by: Jia Jia <physicalmtea@gmail.com> Reported-by: Miku Hatsune <anznu1l@gmail.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <eb7cc3672a20db392f577edbece2300aa6754dd3.1784898967.git.mst@redhat.com>
virtio-mmio reports VIRTQUEUE_MAX_SIZE (1024) as QUEUE_NUM_MAX for every
queue, regardless of the size the device passes to virtio_add_queue().
This works by accident because QEMU mostly does not care about the ring
size - the guest is the one allocating memory here. But this changes
with in-order vqs where qemu is the one allocating resources.
Now, specifying a larger vq than allocated causes an OOB memory access.
To fix:
- for new machine types, report the actual max queue size to guest
- for old machine types, use a compat property to allocate 1k sized
queues
Fixes: 525d82e323 ("virtio: fix queue size validation against allocated maximum") Fixes: CVE-2026-50626
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3882 Cc: Peter Maydell <peter.maydell@linaro.org>
Message-ID: <8715acbb9516e67e2a776cda6f9edf105343f788.1784930765.git.mst@redhat.com> Acked-by: Yonggang Luo <luoyonggang@gmail.com> Reported-by: Miku Hatsune <anznu1l@gmail.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
virtio-scsi: fix SCSIRequest leak on a bad request
When virtio_scsi_handle_cmd_vq() cleans up prepared requests after a
malformed element in the same batch, it drops only one reference even
though virtio_scsi_handle_cmd_req_prepare() leaves each unsubmitted
SCSIRequest with two references. This leaks the request and allows
repeated bad batches to cause unbounded host memory growth.
Add a second scsi_req_unref() and clear hba_private first.
Fixes: CVE-2026-61476 Fixes: 661e32fb3c ("virtio-scsi: convert virtio_scsi_bad_req() to use virtio_error()")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3875 Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Fam Zheng <fam@euphon.net> Cc: Greg Kurz <groug@kaod.org> Reported-by: Feifan Qian <bea1e@proton.me> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <5092cd4716e08d29731bfe85eea82a732b837ff4.1784895264.git.mst@redhat.com>
When vhost_commit() rebuilds the memory region table after a flatview
change, it revalidates cached host virtual addresses for active vring
parts. If a mapping is stale, QEMU abort().
This is not a security problem - only the priviledged guest
can control make it invalid - but not nice e.g. for driver debugging.
Let's call virtio_error() instead, marking the device as broken.
Fixes: 0ca1fd2d68 ("vhost: Simplify ring verification checks")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3783 Cc: Stefano Garzarella <sgarzare@redhat.com> Cc: Dr. David Alan Gilbert <dave@treblig.org> Reported-by: Feifan Qian <bea1e@proton.me> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <71961a7dc157f552303aeea8c99a75c5e1ce904e.1784898432.git.mst@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org>
The split-ring path already rejects a zero-length indirect descriptor
table since commit 7423192912af ("virtio: add checks for the size of
the indirect table"). The packed-ring path is missing the same check,
allowing a guest to trigger an assertion in address_space_cache_init()
with a packed indirect descriptor that has len=0.
Add the same !desc.len check to the packed-ring indirect validation
in both virtqueue_packed_get_avail_bytes() and virtqueue_packed_pop().
Fixes: 86044b24e865 ("virtio: basic packed virtqueue support") Cc: jasowangio@gmail.com Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3984 Reported-by: dong ling <dongling226655@outlook.com> Signed-off-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260715115040.2186274-1-lvivier@redhat.com>
libvhost-user: protect against OOB vring queue access
SET_VRING_NUM, SET_VRING_ADDR, SET_VRING_BASE, and GET_VRING_BASE
handlers all use the queue index from the message to access dev->vq[]
without checking that it is below dev->max_queues, so a malformed
message causes an out-of-bounds heap access.
Frontend is trusted so not a security problem, but
an OOB access is not a nice way to handle errors.
Check, and panic.
libvhost-user: protect against OOB writes in vu_set_inflight_fd
vu_set_inflight_fd() trusts the num_queues value from the
VHOST_USER_SET_INFLIGHT_FD message without checking it against
dev->max_queues, so an oversized value causes out-of-bounds writes to
dev->vq.
Front end is generally trusted so not a security problem, but OOB isn't
a nice way to handle frontend bugs. Let's harden this a bit:
check num_queues and panic if it's invalid.
Fixes: 5f9ff1eff3 ("libvhost-user: Support tracking inflight I/O in shared memory")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3740 Cc: Stefano Garzarella <sgarzare@redhat.com> Reported-by: xlabai <xlabai@tencent.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <23b3f12388c1035f208550df9de9944c22d8d534.1784899127.git.mst@redhat.com>
virtio-net: fix short frame OOB read in receive_filter()
Within virtio-net, receive_filter() reads Ethernet header fields without
any length checks.
But virtio-net sets do_not_pad in NetClientState, so backends such as
socket forward frames at the size supplied by the peer without padding
to the Ethernet minimum. A short frame thus causes an out-of-bounds
read.
Add size checks in receive_filter() and drop the truncated frames.
Fixes: CVE-2026-63320 Fixes: 3831ab2094 ("qemu:virtio-net: Enable filtering based on MAC, promisc, broadcast and allmulti (Alex Williamson)") Cc: Jason Wang <jasowangio@gmail.com> Cc: Alex Williamson <alex@shazbot.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3626 Reported-by: huntr bubble <bubblehuntr@gmail.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <ee5c77b96ab66b2dd518f146def8727216a5c495.1784895727.git.mst@redhat.com>
The RSC receive path parses incoming frames at guest_hdr_len byte
offsets, but the backend buffer contains only host_hdr_len bytes of vnet
header. If the lengths differ, RSC would read at the wrong offset and
cause an OOB read.
This is no longer possible after the previous patch, but the assumption
seem fragile. Along the defense in depth lines, let's validate. To
ensure we are not breaking any valid setups by mistake, warn and fall
back to the normal receive path when host_hdr_len != guest_hdr_len.
Fixes: CVE-2026-63321 Fixes: 2974e916df ("virtio-net: support RSC v4/v6 tcp traffic for Windows HCK") Cc: Jason Wang <jasowangio@gmail.com> Cc: Yuri Benditovich <ybendito@redhat.com> Cc: Wei Xu <wexu@redhat.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3623 Reported-by: huntr bubble <bubblehuntr@gmail.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <f261dcd535edc890f8636d8ae5ac1007bc32b8b4.1784891251.git.mst@redhat.com>
virtio_set_features_nocheck() calls set_features_ex
with guest-supplied feature bits, without masking the value
with host features (unlike set_features which gets the
correct val & host_features).
This does not matter if the driver matches spec, but drivers
can be malicious or buggy and set bit outside the host mask.
Devices don't expect this, so unsupported guest feature bits getting set
can break the host. In virtio-net, this can enable RSC without vnet
header support and cause out-of-bounds reads from short packets.
Pass the masked features to set_features_ex, consistent with set_features.
Fixes: CVE-2026-63321 Fixes: 64a6a336f4 ("virtio: add support for negotiating extended features") Cc: Jason Wang <jasowangio@gmail.com> Cc: Yuri Benditovich <ybendito@redhat.com> Cc: Paolo Abeni <pabeni@redhat.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3623 Reported-by: huntr bubble <bubblehuntr@gmail.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <dfd27c9b26e442a2076f6ddc9bb3d38363d9b2da.1784891251.git.mst@redhat.com>
parallels: fix integer overflow in header size calculation
parallels_open() caches bat_entry_off(s->bat_size) - a uint32_t -
in a plain int before it feeds into s->header_size. Near the
"Catalog too large" bound the value exceeds INT_MAX and overflows
on assignment.
Match the cached value's type to bat_entry_off()'s return type.
Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Thomas Huth <thuth@redhat.com> CC: Stefan Hajnoczi <stefanha@redhat.com>
hw/9pfs: annotate V9fsTransport callbacks as coroutine_fn
All V9fsTransport callbacks are invoked exclusively from coroutine
context (the v9fs_* PDU handlers). Annotate the function pointer
types in V9fsTransport and all implementations (virtio and xen
backends), as well as intermediate callers in 9p.c (pdu_marshal,
pdu_unmarshal, v9fs_init_qiov_from_pdu, etc.).
Acked-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Those DEBUG_ALLOC-guarded are dead code incorrectly calling coroutine fn
from non-coroutine. Remove it.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Fixes: 70bacc44532 ("qcow2: mark more functions as coroutine_fns and GRAPH_RDLOCK") Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The function was extracted without carrying the annotation.
Fixes: 23743ab282af ("block: move commit_run loop to separate function") Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Fixes: 394b9407e4c ("migration: mark mixed functions that can suspend") Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
monitor: annotate monitor_qmp_dispatcher_pop_any() as coroutine
The function calls qemu_coroutine_yield(), and is called from
monitor_qmp_dispatcher_co().
Fixes: 60f4f62efeb ("monitor: extract request dequeuing to a new function") Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Under some optimization, gcc produces a false-positive:
../block/blkio.c: In function ‘blkio_co_getlength’:
../block/blkio.c:943:8: error: ‘ret’ may be used uninitialized [-Werror=maybe-uninitialized]
943 | if (ret < 0) {
| ^
Replace WITH_QEMU_LOCK_GUARD with the simpler QEMU_LOCK_GUARD.
virt_instance_init() built the FDT unconditionally at QOM
instance-init time, so simply instantiating the object (e.g. via
qom-test's introspection, without ever realizing the machine) leaked
the 1MB FDT blob: machine_finalize() does not free machine->fdt.
Other boards (arm/virt, riscv/virt, ...) build the FDT lazily from
their MachineClass::init callback, which only runs when the machine
is actually selected to boot. Do the same here by moving create_fdt()
into virt_init().
hw/display/virtio-gpu-rutabaga: zero-init capset info response
rutabaga_cmd_get_capset_info() only fills in capset_id,
capset_max_version and capset_max_size before sending the response to
the guest. The remaining fields of struct virtio_gpu_resp_capset_info,
including hdr.fence_id, hdr.ctx_id and hdr.ring_idx, are left with
stack garbage and leaked to the guest, including host pointers useful
for an ASLR bypass.
Zero the response first, matching virgl_cmd_get_capset_info().
Not a real risk thanks to -ftrivial-auto-var-init=zero, but only with
gcc >= 12 or clang >= 16.
virtio_gpu_base_device_realize() leaks a migration blocker if a
check of the output list fails after adding one. Perform the check
before adding a migration blocker to avoid the leak. This also
simplifies the code by merging two loops.
The documentation stated that writing to HV_X64_MSR_CRASH_CTL
unconditionally causes the guest to shutdown. In reality, it triggers
qemu_system_guest_panicked() via KVM_SYSTEM_EVENT_CRASH and the
resulting action depends on the generic panic action policy
(-action panic=...), which defaults to shutdown.
virtio-gpu: fix NULL deref in rutabaga set_scanout
rutabaga_cmd_set_scanout() checks scanout_id < VIRTIO_GPU_MAX_SCANOUTS
(16), but does not check scanout_id < conf.max_outputs like the base
class (virtio-gpu.c) and virgl backend (virtio-gpu-virgl.c) do.
With the default max_outputs=1, virtio_gpu_base_device_realize only
initializes scanout[0].con. A guest submitting SET_SCANOUT with
scanout_id >= 1 takes the con=NULL path, and
qemu_console_set_surface(NULL, NULL) dereferences con->ds, crashing
QEMU.
Replace VIRTIO_GPU_MAX_SCANOUTS with vb->conf.max_outputs in the
CHECK, since realization already ensures max_outputs <=
VIRTIO_GPU_MAX_SCANOUTS.
target/i386/sev: fix MemoryRegion reference leaks in gpa2hva callers
gpa2hva() returns a referenced MemoryRegion via its p_mr out-parameter
(inherited from memory_region_find()), but both SEV callers were failing
to release it.
Fixes: c7f7e6970d3b ("sev: add sev-inject-launch-secret") Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260521145451.1831984-1-marcandre.lureau@redhat.com>
net/colo: fix g_hash_table_destroy assertion on uninitialized filter
colo_rewriter_cleanup() unconditionally destroys connection_track_table,
but the table is only allocated in colo_rewriter_setup(). When the
filter-rewriter object is finalized without having been set up (e.g.
during qom-test property enumeration), the pointer is NULL and
g_hash_table_destroy() fires an assertion.
Use g_clear_pointer() to skip the destroy when the table was never
initialized.
hw/display/qxl: unregister vm_change_state handler and BHs
qxl_realize_common() registers a vm_change_state handler via
qemu_add_vm_change_state_handler() and creates three bottom halves
(update_irq, update_area_bh, cursor_bh), but none are ever cleaned up.
The return value of qemu_add_vm_change_state_handler() is discarded, so
the handler is never removed from the global list, and there is no
PCIDeviceClass.exit callback to delete the BHs.
When a secondary QXL device (hotpluggable by default) is hot-unplugged
via device_del, the PCIQXLDevice memory is freed but the vm_state
handler and BH entries remain with dangling opaque pointers. On the
next VM state change (stop/cont/migrate) or BH dispatch, the callback
dereferences freed memory, causing a use-after-free.
Fix this by storing the VMChangeStateEntry returned by
qemu_add_vm_change_state_handler() and adding a qxl_exit() callback
that deletes the vm_state handler, all three BHs, and the
guest_surfaces.cmds allocation before the device memory is freed.
A malicious or buggy vhost-user-gpu backend can send messages with
undersized payloads, leading to out-of-bounds reads when the handler
accesses struct fields beyond the allocated buffer. However,
vhost-user-gpu is considered trusted by QEMU by design (it has access to
shared memory etc).
Add a centralized minimum payload size check in vhost_user_gpu_chr_read()
that rejects messages before dispatch, and a per-pixel bounds check in
the VHOST_USER_GPU_UPDATE handler to ensure the variable-length data
covers the declared width x height.
virtio_gpu_do_set_scanout() validates the stride field of struct
virtio_gpu_framebuffer against the bytes_pp field, but bytes_pp in the
migration stream may be inconsistent with the format field, which
pixman_image_create_bits() uses when it accesses the framebuffer.
That validation is therefore incomplete.
To avoid the trouble of synchronizing the two fields, remove bytes_pp,
and always derive its value from format. Removing bytes_pp is safe
because no released version of QEMU uses its migrated value.
Fixes: 7b5574225429 ("hw/display: check frame buffer can hold blob") Cc: qemu-stable@nongnu.org Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
[ Marc-André - fix rebase conflict ] Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-ID: <20260719-bpp-v1-1-9b91946d6cf3@rsg.ci.i.u-tokyo.ac.jp>
Thomas Huth [Fri, 24 Jul 2026 11:09:33 +0000 (13:09 +0200)]
hw/usb/hcd-xhci: Check return value of xhci_xfer_create_sgl() for errors
xhci_xfer_create_sgl() can fail if a guest programmed the XHCI in
a weird way. The current code ignores this error, and this triggers
an assert() shortly afterwards:
Fix it by handling the error correctly (i.e. return with an error to
the caller).
While we're at it, change the DPRINTF statements in xhci_xfer_create_sgl()
into proper qemu_log_mask() statements, so we have a better way to detect
this situation.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3786 Reported-by: Feifan Qian <bea1e@proton.me> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260724110933.629791-1-thuth@redhat.com>
Thomas Huth [Tue, 21 Jul 2026 18:51:40 +0000 (20:51 +0200)]
hw/usb/core: Avoid possible assert() in do_parameter() --> usb_packet_copy()
usb_packet_copy() uses assert(p->actual_length + bytes <= iov->size)
to make sure that there is enough space in the the iov. This assert()
can be triggered from do_parameter() if the guest programs the XHCI
in a weird way. Avoid the hard error by checking for the condition
in do_parameter() first and signalling a USB_RET_STALL to the guest,
just like it is done for another error condition here already some
lines earlier.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3746 Reported-by: Yunhe Wang <yunhewwww@163.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260721185140.247775-1-thuth@redhat.com>
Thomas Huth [Tue, 21 Jul 2026 07:02:16 +0000 (09:02 +0200)]
hw/ide/core: Fix possible crash via NULL pointer in ide_cancel_dma_sync()
ide_cancel_dma_sync() is called with a "IDEState *s" for one of the
two IDE drives on a bus (primary or secondary drive) to cancel all
pending DMA transfers on the drive. The code then checks
s->bus->dma->aiocb to see whether there is any IO in flight on the
*bus* and then calls blk_drain(s->blk) to wait for its completion.
However, s->bus->dma->aiocb might belong to the other drive on the
bus, and if there is no disk attached to the current drive, s->blk
is NULL. Since blk_drain() does not check its parameter for a NULL
pointer, QEMU can crash in such a case.
To fix the problem, we have to check that "blk" is not NULL before
calling blk_drain(). And we have to call blk_drain() for both drives,
otherwise the assert(s->bus->dma->aiocb == NULL) statement after
the blk_drain() might trigger if the IO in flight belongs to the
the other drive.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/905 Reported-by: Alexander Bulekov <alxndr@bu.edu>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4052 Reported-by: dong ling Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260721070216.82984-1-thuth@redhat.com>
The stream ID is under control of the guest, and some spots in the
code currently use it for indexing into the status3[] array without
checking it for being in range first, so the code accesses the heap
beyond the limit of the status3 array.
Since our status delivery code depends on having a valid stream ID,
we must not try to generate a fake sense code in this situation.
Simply log a guest error and return early in usb_uas_command().
And to make sure that we really cannot access the status3[] array
beyond its limit anymore, add some assert() statements in the
affected functions, too.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3612 Reported-by: Reported-by: huntr bubble
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3986 Reported-by: Tristan Madani <tristan@talencesecurity.com> Suggested-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260720134809.573757-1-thuth@redhat.com>
Feifan Qian [Fri, 12 Jun 2026 15:37:53 +0000 (15:37 +0000)]
hw/cxl: Validate Set Feature payload bounds
cmd_features_set_feature() derives bytes_to_copy from the mailbox input
length and uses hdr->offset as the destination offset into per-feature
write attribute buffers.
The patrol scrub and ECS paths already reject writes where hdr->offset
plus bytes_to_copy exceeds the destination structure. Add the same check
to the soft PPR, hard PPR and memory sparing feature paths before
copying into their write attribute buffers.
Without the check, a malformed Set Feature request can write past the
selected write attribute object and corrupt adjacent CXL type 3 device
state.
Fixes: 5e5a86bab830 ("hw/cxl: Add support for Maintenance command and Post Package Repair (PPR)") Fixes: da5cafdc4ddd ("hw/cxl: Add emulation for memory sparing control feature") Signed-off-by: Feifan Qian <bea1e@proton.me> Reviewed-by: Thomas Huth <thuth@redhat.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3458 Reported-by: Jia Jia <physicalmtea@gmail.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Commit b04746bd0d7c unified boot completion detection on the generic
'login:' prompt but missed several SDK test files that still matched
on hostname-prefixed patterns. Apply the same fix.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4059 Fixes: b04746bd0d7c ("tests/functional/aspeed: unify boot completion detection on 'login:' prompt") Reported-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Link: https://lore.kernel.org/qemu-devel/20260720162321.3497633-1-clg@redhat.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Building linux-user on a host with Linux 7.2 kernel headers fails with
a macro redefinition error for FUTEX_CMD_MASK. The kernel commit 3ca9595d9fb6 ("futex: Add support for unlocking robust futexes")
expanded the mask to include the new FUTEX_ROBUST_UNLOCK and
FUTEX_ROBUST_LIST32 flags, which conflicts with QEMU's local
definition.
Add a #ifndef guard so the host definition takes precedence when
available. The local fallback is kept for older kernel headers
(pre-2.6.29) that lack FUTEX_CMD_MASK or define a mask without
FUTEX_CLOCK_REALTIME.
Signed-off-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Signed-off-by: Helge Deller <deller@gmx.de>
hw/9pfs/xen: drain in-flight PDUs before xen-9p disconnect
The xen-9p disconnect path has two issues:
1. It frees the Xen9pfsRing structures while in-flight PDUs may still
reference them via pdu->tag to index rings[]. This causes a UAF
in xen_9pfs_push_and_notify() when worker threads resume after
completing filesystem operations.
2. It never calls v9fs_device_unrealize_common(), which means server
state (struct LocalData, mountfd, FIDs) is never cleaned up on
disconnect, causing a resource leak on every guest-initiated
disconnect.
Fix both by draining in-flight PDUs via v9fs_reset() before tearing
down rings, and calling v9fs_device_unrealize_common() to clean up
server state.
Additionally, explicit calls of xen_9pfs_disconnect() in the error
paths of xen_9pfs_pdu_vmarshal() and xen_9pfs_pdu_vunmarshal() must
be deferred (via aio_bh_schedule_oneshot()), because
xen_9pfs_pdu_v(un)marshal() are running within a coroutine context
which makes them unsafe [1] for calling v9fs_reset() directly, as
the latter e.g. has a loop like:
while (!QLIST_EMPTY(&s->active_list)) {
aio_poll(qemu_get_aio_context(), true);
}
which would a) never terminate (as the coroutine is on the
active_list) and b) aio_poll() is marked as no_coroutine_fn.
And finally, add an idempotent guard to xen_9pfs_disconnect()
for the v9fs_reset(s) and v9fs_device_unrealize_common(s) calls
specifically [2], just to be sure.
hw/9pfs/virtio: drain in-flight PDUs before virtio-9p unrealize
A guest can trigger a heap-use-after-free in the virtio transport
unrealize path by submitting a Treaddir request and immediately
ejecting the device via ACPI PCI hotplug. The unrealize path frees
struct LocalData while a worker thread still holds a reference
on it, causing a UAF in local_open_nofollow().
Fix this by draining all in-flight 9p PDUs by calling v9fs_reset()
before final server cleanup. This ensures all coroutines completed,
all FIDs are closed, and no worker thread still holds references
on 9p server state when it is freed.
Guest 9p client opening a file with O_TRUNC on a read-only 9p file
system using 9p2000.u protocol version, allowed to bypass 9p
server's read-only check, eventually causing file(s) being
truncated to empty file(s) on host's read-only export.
Root cause is that 9p server's read-only check is using Linux open
flags like O_WRONLY, O_RDWR, O_TRUNC, but checking them against
the 9p Topen request's "mode" parameter, which has a different
encoding (Otrunc = 0x10 vs. O_TRUNC = 0x200).
Fix this by checking against the "flags" variable instead of the
protocol's "mode" option. Because the "flags" variable is already
converted to Linux encoding by omode_to_uflags() for 9p2000.u and
by get_dotl_openflags() for 9p2000.L protocol version.
Only 9p2000.u was affected by this bypass, 9p2000.L uses the Linux
format on protocol level already.
Fixes: 2c74c2cb4b ("hw/9pfs: Read-only support for 9p export") Fixes: CVE-2026-63318
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/4000 Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Link: https://lore.kernel.org/qemu-devel/E1wk2Dq-0019kY-JK@kylie.crudebyte.com Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
On host systems with ext4 and ea_inode capability not enabled, the max. size
for xattr values is slightly below 4k, which caused the new xattr tests to
fail on such host systems.
Reduce the xattr size for our tests to 1k to prevent them to fail on such
host systems.
tests/9p: prevent potential error in do_local_xattr_limit()
The local fs backend driver tests require that a dummy file is
created on the host side before running the xattr limit tests,
otherwise the test will fail because the file is expected to exist.
The original call of g_file_set_contents() didn't check its
return value, which might cause subsequent test checks to fail,
making it harder to identify the root cause.
Fix this by simply wrapping the call into a g_assert().
Fixes: 04a62cdfe873 ("tests/9p: add 3 xattr FID limit test cases (local fs driver)")
CID: 1660926 Tested-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Link: https://lore.kernel.org/qemu-devel/E1wfg2F-001Sfn-Rr@kylie.crudebyte.com Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Stefan Hajnoczi [Fri, 24 Jul 2026 13:13:48 +0000 (09:13 -0400)]
Merge tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu into staging
trivial patches for 2026-07-24
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEZKoqtTHVaQM2a/75gqpKJDselHgFAmpjNGwACgkQgqpKJDse
# lHgNTQ/9HIA3y8yT624Jk6G89QS++yk4J+uIILBWnPOSL1DxHT3sIpkgZ7eoTDmx
# 6ivno8dIssTvBZ9VJBlt6gy1c70KJH2sk4csZ9LA89FoGcm+VpV+hLWoqihiYvkr
# 59JGdMqrAqiYT0DXIYFQGUVtwquFPKSifrQv+zR4PwXhm8yMwSMPI4OPWUEm3Nm9
# PTwZrPY07khCdtF4/x5zn4NZoOcolPVP1/cMjY1VaHY350/4HQr2Xh4tL7X/tqfJ
# TBoEzRDIP+ts/xa9KWd2lxi9v7bjZbT9FbqfmmY1iqkd6nOH7hY65UIjxEA0kAP6
# gW74czuBHYLpPnS9z4kC0Zh4oZohaz5e46IcPps5nr8z2DqEJ2HPnV9MCGHKEa8Q
# 40P7zlDU17RcvMN9Ymv9TzlPyg/y3MlhwWMDcW+D3l7SX5bCBQXjAdF+fa1njFBk
# A91jr92Z68uYgqEIvlFZJzhdF2X0NWd9SaLnXx9IlIYNOU2dcqoo2yOGlROAwc4s
# goJbLQLWT9+2eyl/l7xrJR0DPDA5QZAQNCnJ6qbCga6jKpJxzIgcfMu+V7sKZJU4
# zfzEzu17uocszZd4apeK24TvJlY6rZfV878oJ31qmikxx9wkWSuThNS1luuu+Esl
# jkDvAGyhmNVHoie5ds1C+AHBTxZyiWk4ipSINS4WB+muC8UWuJA=
# =vHq8
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 24 Jul 2026 05:46:20 EDT
# gpg: using RSA key 64AA2AB531D56903366BFEF982AA4A243B1E9478
# gpg: Good signature from "Michael Tokarev <mjt@debian.org>" [unknown]
# gpg: aka "Michael Tokarev <mjt@corpit.ru>" [unknown]
# gpg: aka "Michael Tokarev <mjt@tls.msk.ru>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E
# Subkey fingerprint: 64AA 2AB5 31D5 6903 366B FEF9 82AA 4A24 3B1E 9478
* tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu:
hw/ide: replace assert with proper error handling
hw/usb: record async control completion for parameter transfers
hw/hyperv/vmbus: Use QEMU_LOCK_GUARD()
hw/display/vmware_vga: Don't allow guest to trigger long running loop in host
block/curl: set User-Agent header
char-win-stdio: fix typo in spelling of 'stdio'
spelling: happend
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
In ide_dma_cb(), the call to prepare_buf() might return a negative
result and cause an assertion failure. This was found during fuzzing
and can be triggered with some qtest commands. Replace the assert with
proper error handling in case the result is negative, but keep the
assert for failing to respect the limit upon success. If that happens,
it is an implementation error.
Found by Linux Verification Center (linuxtesting.org) with libFuzzer.
Cc: qemu-stable@nongnu.org Fixes: ed78352a59 ("ide: Fix incorrect handling of some PRDTs in ide_dma_cb()")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/2777 Signed-off-by: Artem Nasonov <anasonov@astralinux.ru> Link: https://lore.kernel.org/qemu-devel/20250116111600.2570490-1-anasonov@astralinux.ru
[FE: improve commit message
keep assert for failing to respect the limit] Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Ziyi Fu [Fri, 26 Jun 2026 08:05:53 +0000 (10:05 +0200)]
hw/usb: record async control completion for parameter transfers
Record the completion side of parameter-based control transfers when they
complete asynchronously. This lets pcap captures include descriptor
response data for requests such as GET_DESCRIPTOR from usb-host devices.
The synchronous path already recorded the completion, but the async
SETUP_STATE_PARAM path was missing it.
Signed-off-by: Ziyi Fu <ziyi.fu@cyberus-technology.de> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Fixes: 0f6dba145a4b ("usb: add pcap support.") Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Replace manual qemu_mutex_(un)lock() calls with
QEMU_LOCK_GUARD() to remove 'goto out' code
Signed-off-by: Evgeny Kolmakov <randomjack94dev@gmail.com> Reviewed-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Thomas Huth [Thu, 23 Jul 2026 12:44:32 +0000 (14:44 +0200)]
hw/display/vmware_vga: Don't allow guest to trigger long running loop in host
The code in the SVGA_CMD_DEFINE_ALPHA_CURSOR handler in vmsvga_fifo_run()
basically does:
x = vmsvga_fifo_read(s);
y = vmsvga_fifo_read(s);
args = x * y;
goto badcmd;
...
badcmd:
len -= args;
if (len < 0) {
goto rewind;
}
while (args--) {
vmsvga_fifo_read(s);
}
Thus by supplying huge values for x and y that overflow the result of
the multiplication, the guest can trigger a long-running loop here
that burns the host's CPU cycles.
Add some sanity checks so that this cannot happen anymore.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3782 Reported-by: Feifan Qian <bea1e@proton.me>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4026 Reported-by: Tristan Madani <tristan@talencesecurity.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4076 Reported-by: Sunday Jiang Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Vladimir Lobanov [Wed, 17 Jun 2026 09:44:56 +0000 (12:44 +0300)]
block/curl: set User-Agent header
Some HTTP servers and WAFs (e.g. Amazon CloudFront) reject
requests without a User-Agent header with 403 Forbidden. This
makes qemu-img info and other curl-based operations fail on
such URLs without any obvious indication of the root cause.
Set a "QEMU/<version>" User-Agent string on all curl handles
to ensure compatibility with these endpoints.
Signed-off-by: Vladimir Lobanov <lobanov-vla@yandex.ru> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Filip Hejsek [Thu, 18 Jun 2026 11:20:18 +0000 (13:20 +0200)]
char-win-stdio: fix typo in spelling of 'stdio'
Signed-off-by: Filip Hejsek <filip.hejsek@gmail.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Stefan Weil <sw@weilnetz.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Stefan Hajnoczi [Wed, 22 Jul 2026 15:17:29 +0000 (11:17 -0400)]
Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging
* meson: propagate qemu_ldflags to Rust link step
* target/i386: helper_sysret(): Check that RCX contains a canonical address when emulating an Intel CPU
* target/i386: tcg: remove FIXME
* scsi-disk: protect against guest sending truncated data for MODE SELECT commands
* scsi-disk: fix off by one in assertion
* tag 'for-upstream' of https://gitlab.com/bonzini/qemu:
scsi-disk: fix off by one in assertion
scsi-disk: protect against guest sending truncated data for MODE SELECT commands
target/i386: helper_sysret(): Check that RCX contains a canonical address when emulating an Intel CPU
meson: propagate qemu_ldflags to Rust link step
target/i386: tcg: remove FIXME
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Wed, 22 Jul 2026 15:17:01 +0000 (11:17 -0400)]
Merge tag 'pull-vfio-20260721' of https://github.com/legoater/qemu into staging
vfio queue:
* Fix IGD legacy VBIOS ROM to clear saved BDSM at load time, avoiding
garbled BIOS POST output
* Clarify dma-buf failure messages for P2P DMA
* Fix config read error handling and reject invalid PCI_INTERRUPT_PIN
values in vfio/pci
* Harden vfio-user: prevent buffer overflows, excessive mallocs, and
fix region info capability check
This was never meant to be present in production builds. It's a code
path not hit on a normal boot (OVMF wouldn't try variable updates which
are not allowed), so this went unnoticed.
Remove the function. If needed for debugging the git log is your
friend.
Paolo Bonzini [Tue, 21 Jul 2026 15:56:42 +0000 (17:56 +0200)]
scsi-disk: fix off by one in assertion
When documenting the invariant that mode pages need to fit the smallest
output buffer of all callers (which is SCSI_MAX_MODE_LEN), the expression
used by the assertion was incorrect.
Even though SCSI_MAX_MODE_LEN is indeed 256, using "length < 256" had
two issues: 1) it used the wrong operator, since "length < ..." is more
related to having room for extra data; 2) it missed the extra two bytes
for page number and length.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Tue, 21 Jul 2026 15:22:11 +0000 (17:22 +0200)]
scsi-disk: protect against guest sending truncated data for MODE SELECT commands
scsi-disk has a MODE SELECT path where a truncated mode page can be
allowed by a compatibility quirk, but the parser continues to use the
page's declared length rather than the number of bytes actually remaining
in the request buffer. This means that scsi_disk_check_mode_select() and
scsi_disk_apply_mode_select() can read beyond the valid part of inbuf[],
potentially up to the emulated age's length.
Clamping page_len (the size of the page) to len (whatever the
guest provided) ensures that scsi_disk_check_mode_select() and
scsi_disk_apply_mode_select() do not access anything beyond bounds;
however, this requires care to accept and handle truncated input in
those two functions.
In particular, until scsi_disk_check_mode_select()'s first call to
mode_sense_page() the number of bytes to be cleared in mode_current[] is
unknown, so zero it completely. And for everything else, be conservative
and use len when providing inputs to other functions; but at the same time,
ensure all accesses to inbuf[] are bound by expected_len.
Note that pages longer than the emulated one are still rejected.
Fixes: 389e18eb9aa4 ("scsi-disk: add SCSI_DISK_QUIRK_MODE_PAGE_TRUNCATED quirk for Macintosh")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4051 Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
We recently started to have those failures appearing when building
documentation. It's hard to identify if it comes from a python, sphinx
or sphinx extension, but it blocks us.
Exception occurred:
File "/usr/lib/python3.13/multiprocessing/connection.py", line 399, in _recv
raise EOFError
EOFError
The full traceback has been saved in /tmp/sphinx-*.log, if you want to report the issue to the developers.
This seems to be the generic error message for "something went wrong in
sphinx multiprocess":
- https://github.com/sphinx-doc/sphinx/issues/11449
- https://github.com/sphinx-doc/sphinx/issues/14458
- https://github.com/sphinx-doc/sphinx/issues/8973
Solve the issue by simply going back to sequential builds. We didn't
notice a huge speedup anyway.
Andrey Polivoda [Mon, 8 Jun 2026 09:18:15 +0000 (19:18 +1000)]
target/i386: helper_sysret(): Check that RCX contains a canonical address when emulating an Intel CPU
Intel and AMD CPUs implement SYSRETQ instruction differently.
One of these differences is whether a canonicality check of the address that
will be loaded to RIP is performed: Intel CPUs do this check, AMD CPUs don't.
Currently, QEMU does not perform this check when emulating Intel CPUs.
This patch corrects this by implementing the canonlicality check on a new RIP
value from RCX and performing it only when emulating Intel CPUs.
Flags and segment registers' caches are updated only after checking the new RIP
value to ensure that CPU state is not modified in case the #GP(0) exception
is raised due to the check failure.
Cc: qemu-devel@nongnu.org Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <richard.henderson@linaro.org> Fixes: 14ce26e75513 ("x86_64 target support")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3223 Signed-off-by: Andrey Polivoda <apolivodaa433@gmail.com> Link: https://lore.kernel.org/r/20260608091815.31303-1-apolivodaa433@gmail.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Brian Cain [Tue, 14 Jul 2026 02:12:36 +0000 (19:12 -0700)]
meson: propagate qemu_ldflags to Rust link step
Sanitizer flags are added to qemu_ldflags and applied globally for
all_languages, but all_languages never includes 'rust'.
Fixes link errors like the ones below:
-Wl,-rpath,$ORIGIN/../qemu-macros:<sysroot>/lib/rustlib/x86_64-unknown-linux-gnu/lib"
= note: some arguments are omitted. use `--verbose` to show all linker arguments
= note: rust-lld: error: undefined symbol: __ubsan_handle_type_mismatch_v1
>>> referenced by event-loop-base.c:104 (../qemu_before_fix/event-loop-base.c:104)
>>> libevent-loop-base.a.p/event-loop-base.c.o:(event_loop_base_class_init)
>>> referenced by event-loop-base.c:105 (../qemu_before_fix/event-loop-base.c:105)
>>> libevent-loop-base.a.p/event-loop-base.c.o:(event_loop_base_class_init)
>>> referenced by event-loop-base.c:58 (../qemu_before_fix/event-loop-base.c:58)
>>> libevent-loop-base.a.p/event-loop-base.c.o:(event_loop_base_set_param)
>>> referenced 11240 more times
The existing check for PCI capabilities misses the case where
info->cap_offset == info->argsz, which results in accessing unallocated
memory. Fix the comparison.
If the vfio-user server responds with a value larger than max_xfer_size
vfio_device_get_region_info() blindly uses it in the next loop in
g_realloc. An value larger than max_xfer_size is anyway rejected by the
check at the beginning of vfio_user_get_region_info(), however that only
happens _after_ the g_realloc, and if that value is excessively large it
can cause g_realloc to fail, so check it here.
projects / thirdparty / qemu.git / log
