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.
If the vfio-user responds with a value large enough such that adding
the header size to it overflows, a smaller buffer would be
inadvertently allocated, leading to buffer overflow.
qemu-kvm aborts a few seconds after starting a VM with a
passed-through GPU whose PCI_INTERRUPT_PIN comes back as an
out-of-range value: vfio_intx_enable() only guards against pin == 0
and stores vdev->intx.pin = pin - 1 with no upper-bound check. That
value later reaches pci_irq_handler()'s
assert(0 <= irq_num && irq_num < PCI_NUM_PINS) via
pci_irq_deassert() -> pci_set_irq(), aborting the process.
Legal PCI_INTERRUPT_PIN values are 0 (no legacy interrupt) or
1-PCI_NUM_PINS (INTA-INTD); reject anything else before it reaches
vdev->intx.pin, whether the out-of-range value came from a read
failure (now caught by the previous commit) or was handed back as
data by the device itself.
Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Alex Williamson <alex@shazbot.org> CC: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20260717122232.468955-3-den@openvz.org Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
vfio/pci: don't narrow a failed config read to a plausible value
vfio_pci_read_config() signals a failed host-side read by returning
(uint32_t)-1, regardless of the requested length. vfio_intx_enable()
and vfio_pci_pre_reset() both narrowed that return value straight
into a uint8_t/uint16_t local before checking anything, which
truncates -1 into 0xff or 0xffff - values a real 1- or 2-byte
register read can legitimately produce. From that point on, a
failed read and real all-ones content are indistinguishable.
Keep the full uint32_t result and check it against (uint32_t)-1
before narrowing. In vfio_pci_pre_reset(), skip the corresponding
write-back on a failed read instead of writing back constructed
garbage to the device.
Resolves: Coverity CID 1663684
Resolves: Coverity CID 1663688 Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Alex Williamson <alex@shazbot.org> CC: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20260717122232.468955-2-den@openvz.org
[ clg: Added Coverity IDs ] Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
The dma-buf failure messages in vfio_region_create_dma_buf() say "PCI
BAR IOMMU mappings may fail", which suggests the BAR is broken. In
practice, only P2P DMA is affected -- normal passthrough uses the mmap
fallback.
Reword both messages to mention P2P DMA explicitly and clarify that
the mmap fallback is in use. Use warn_report_err_once() at the call
site so per-BAR repetition on mdev devices is suppressed.
Fixes: dcf1b77e834d ("hw/vfio/region: Create dmabuf for PCI BAR per region") Cc: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
vfio/igd: Clear saved BDSM in legacy VBIOS ROM at load time
IGD does not come with a ROM BAR [1], the ROM BAR read by default from
kernel is actually the host VBIOS shadow RAM region that contains host
modifications on boot. With AI-assisted reverse engineering on VBIOS
binaries, it is observed that VBIOS saves BDSM register value on first
access and uses saved value if present.
When the image is executed in guest, since there is already a saved HPA
in VBIOS, it keeps using that value instead of the GPA programmed by
SeaBIOS in BDSM register in PCI config space, causing VBIOS to program
GTT entries with wrong address, resulting in garbled output in BIOS
POST and the error below detected by i915 driver.
The previous solution, c4c45e943e51 ("vfio/pci: Intel graphics legacy
mode assignment"), adjusts GTT entry addresses to (addr - host BDSM +
guest BDSM) to workaround that. But it is removed in 5aed8b0f0be2
("vfio/igd: Remove GTT write quirk in IO BAR 4") due to inconsistent
values in MMIO BAR0 and IO BAR4.
Since it was a value latched into the VBIOS that breaks virtualization
(QEMU does not map the GTT at the same address in the VM), a ROM quirk
clearing the saved value in VBIOS image is introduced. It searches the
BDSM accessor routine by matching a 19-byte signature anchored on the
unique `mov $0x105e,%ax` instruction, then locates the offset of saved
BDSM and clears it. This makes the routine fall through to the PCI
config read on the first call inside the guest.
Fixes: 5aed8b0f0be2 ("vfio/igd: Remove GTT write quirk in IO BAR 4")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3093 Reported-by: K S Maan <kirandeepmaan45@gmail.com> Cc: qemu-stable@nongnu.org Signed-off-by: Tomita Moeko <tomitamoeko@gmail.com> Reviewed-by: Alex Williamson <alex@shazbot.org> Link: https://lore.kernel.org/qemu-devel/20260708103100.23127-1-tomitamoeko@gmail.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
get_maintainer: add ability to report Git Lab handle
With the GitLab mapping files from the previous commit, the
get_manitainer.pl script is now able to report the gitlab
handle for each maintainer/reviewer when displaying output.
For example:
$ ./scripts/get_maintainer.pl -f hw/scsi/lsi53c895a.c
Paolo Bonzini <pbonzini@redhat.com> (supporter:SCSI, gitlab:@bonzini)
Fam Zheng <fam@euphon.net> (reviewer:SCSI, gitlab:@famzheng)
qemu-devel@nongnu.org (open list:All patches CC here)
Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
gitlab: introduce files mapping GitLab accounts to real names
It is desirable to be able to discover the GitLab account handle
assocaited with a real name in the MAINTAINERS file.
Rather that duplicating the same account handle multiple times,
inline with the MAINTAINERS file entries, this introduces mapping
files:
* .gitlab-map-auto - data automatically queried from GitLab
using the 'glab' tool and REST API
* .gitlab-map-manual - manual overrides/augmentation for
cases where the MAINTAINERS real name does not match the
GitLab account real name
The former would need refreshing when we add new MAINTAINERS
entries, if the person had to be added as a GitLab account
member. For this purpose scripts/gitlab-map-update can be
used, assuming the user has the 'glab' client tool present
and configured with an access token.
To audit how many maintainers have GitLab handles present/missing
scripts/gitlab-map-check can run a report.
$ ./scripts/gitlab-map-check
Missing GitLab handle for maintainer 'Akihiko Odaki'
Missing GitLab handle for maintainer 'Albert Esteve'
....
Missing GitLab handle for maintainer 'Zhenzhong Duan'
Missing GitLab handle for maintainer 'Zhuoying Cai'
GitLab handles missing: 158 / present: 68
Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
c4b3d0074 removed the check that nettle or gcrypt were explicitly
requested as the crypto library to use, breaking the --enable-nettle and
--enable-gcrypt options. Re-add the logic to force usage of nettle or
gcrypt for crypto operations, while still keeping gnutls for TLS.
Fixes: c4b3d0074 (crypto: bump min gnutls to 3.7.5) Tested-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Luc Michel <luc.michel@amd.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This avoids an interactive prompt that halts execution when
attempting to run the FreeBSD tests due to outdated 14.3
base image:
`Bootstrapping pkg from pkg+https://pkg.FreeBSD.org/FreeBSD:14:amd64/quarterly, please wait...
Verifying signature with trusted certificate pkg.freebsd.org.2013102301... done
Installing pkg-2.6.2_1...
Newer FreeBSD version for package pkg:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1404000
- running userland: 1403000
Ignore the mismatch and continue? [y/N]:
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
test-util-filemonitor: Adapt to FreeBSD 15's native inotify semantics
FreeBSD 15 introduces a native inotify implementation rather than
requiring use of the kqueue-based libinotify package. This native
implementation does not generate the extra deleted events, so don't
expect them. However, the original implementation did have a bug that
caused IN_IGNORED to never be generated if you did not also watch for
IN_DELETE_SELF, which affects 15.0 and 15.1, but has been fixed and will
no longer apply in 15.2 / 16.0.
Note that the deleted event check is for the userspace version, since
that governs whether libinotify is being used or not, whereas the
ignored event check is both for the userspace version (to check if we're
using the native syscall) and the kernel version (to check if the kernel
has the bug or not).
All __FreeBSD_version values used here correspond to the value in-tree
at the time of the relevant commits. Since neither commit bumped the
value there will be a window of development snapshots between each
commit and the previous bump that will be incorrectly identified here,
but this is the best we can do, and something users of snapshots should
be prepared to deal with.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Alex Bennée [Mon, 20 Jul 2026 18:04:59 +0000 (19:04 +0100)]
gitlab: remove gdb from MacOS jobs
The gdb jobs fail on CI and although I can't replicate locally on the
machine I have access to it definitely fixes it for the gitlab CI
machines.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Message-ID: <20260720180459.2542918-1-alex.bennee@linaro.org>
[This fixes the following CI jobs: aarch64-macos-15-build and
aarch64-macos-26-build.
Removing gdb from macOS jobs skips the softmmu gdbstub tests which
currently hang on GitLab's macOS runners:
The following GitLab work item tracks solving the underlying issue that
is hanging softmmu gdbstub tests:
https://gitlab.com/qemu-project/qemu/-/work_items/4063
--Stefan] Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* tag 'hw-misc-20260714' of https://github.com/philmd/qemu:
vfio/listener: Remove unnecessary 'linux/kvm.h' include
hw/audio/intel-hda: restrict all DMA engine paths to memories
hw/sd/sdcard: Fix error case for CMD18
hw/net/cadence: Return current Cadence GEM queue pointers
hw/misc/applesmc: Fix a typo setting MSSD key
replay: fix use of uninitialized pointer on error
user/guest-host: Include exec/abi_ptr.h
hw/display/qxl: validate monitors_config heads[] in phys2virt
net: Correct padding check in qemu_receive_packet()
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* tag 'pull-target-arm-20260721' of https://gitlab.com/pm215/qemu:
Revert "target/arm: Build cpu32-system.o as common object"
MAINTAINERS: Add soc_dma to OMAP section
include/hw/arm/omap_dma.h: Move to include/hw/dma
hw/dma/soc_dma: Remove unused mem.base, paddr fields
hw/dma/soc_dma: Use physical_memory_map() for mem2mem transfers
hw/dma/soc_dma: dma bytes is uint64_t
hw/dma/omap_dma: Be more careful about overflow in transfer setup
hw/dma/soc_dma: Remove union from memmap_entry_s struct
hw/dma/soc_dma: Simplify soc_dma_ch_update()
hw/dma/soc_dma: Remove soc_dma_port_fifo support
target/arm: Fix testing of raw mtx value
target/ppc: Remove unused helper_lscbx()
target/arm: GICv5 cpuif: Writes to ICC_APR_EL1 can change IRQ/FIQ
target/arm: GICv5 cpuif: gicr_cdia_read() ppibit should be 64 bits
hw/net/xilinx_axienet: Fix PHY register 17 link status reporting
hw/char: imx_serial: add missing migration state
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Tue, 21 Jul 2026 14:05:29 +0000 (10:05 -0400)]
Merge tag 'pbouvier/pr/plugins-20260720' of https://gitlab.com/p-b-o/qemu into staging
Changes:
- [PATCH 0/3] dlcall: correct the syscall number claim and the guest (Ziyang Zhang <functioner@sjtu.edu.cn>) Link: https://lore.kernel.org/qemu-devel/20260719074730.1520517-1-functioner@sjtu.edu.cn
# -----BEGIN PGP SIGNATURE-----
#
# iQGzBAABCgAdFiEEN8FWlNi6l2Sxlz/btEQ30ZwoYt8FAmpef1oACgkQtEQ30Zwo
# Yt9/RQv8CqO4yZnBiNnuSlxgz740t7N+5HZDIqP9LR4htpLbdw9FG7NLs179ZME2
# aZ2gQGGMutlh8CuZHGs9A587mQT0sBd6KLmSfMcwyM9FnXw5ewzJqQsZ8YmbKwyM
# nT4BB9OyYJ0RSndov7iAj1EHn7YyDXr4NoVMdRVv8QCXMin9ztgxcHph4D+AsAHe
# 0D+iO1aT88pSuYOWMya1XQln/NkL7cQq3NY8w7IdlMA+edDUcmv0LazQRljywxS+
# IIcGvVcreUlu/v1w9bbqYrI3BualHVdqkbNAQyNuSNSqAQnHkFb9EKcpY4gpe+ZS
# oeoIrHFYu0VM50C/mAE8m+I+iRgJGAlyCaNohpYVj5MQdVZ+hlZx2vpvWGV+4zHG
# GrtRvjVhND88GEsYj5pigQS9HMOZ4FnrSjyQ0t6uI6lcKDeCtfTbz8Q49VUD7okA
# eO3/JLYJPcrdipFjwfM/ahTXpkgejgCJypD90vCIZpO6UF8A1dp7Fl/07XFXDouz
# 5b6YkWGE
# =i09L
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 20 Jul 2026 16:04:42 EDT
# gpg: using RSA key 37C15694D8BA9764B1973FDBB44437D19C2862DF
# gpg: Good signature from "Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>" [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: 37C1 5694 D8BA 9764 B197 3FDB B444 37D1 9C28 62DF
* tag 'pbouvier/pr/plugins-20260720' of https://gitlab.com/p-b-o/qemu:
docs/about/emulation: sharpen the dlcall boundary and its guest requirements
tests/tcg: correct why the magic syscall number is safe here
contrib/plugins/dlcall: correct the syscall number claim, note the data model
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
vfio/listener: Remove unnecessary 'linux/kvm.h' include
Since commit d0e8bccafc23 ("hw/vfio/listener.c: remove CONFIG_KVM"),
the linux/kvm.h include is unconditional. This breaks the build on
targets that lack asm/kvm.h such as sparc and sparc64:
In file included from ../hw/vfio/listener.c:23:
linux-headers/linux/kvm.h:16:10: fatal error: asm/kvm.h: No such file or directory
This include is not needed in listener.c which only uses kvm_enabled()
and kvm_get_max_memslots(), both are declared in "system/kvm.h".
Remove it.
Fixes: d0e8bccafc23 ("hw/vfio/listener.c: remove CONFIG_KVM") Cc: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>" Suggested-by: Alex Williamson <alex@shazbot.org> Signed-off-by: Cédric Le Goater <clg@redhat.com> Tested-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260721062745.3793066-1-clg@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
hw/audio/intel-hda: restrict all DMA engine paths to memories
CVE-2021-3611 (commit 79fa99831d) restricted the DMA engine to memories
by setting attrs.memory=true, but only applied this to intel_hda_response.
Three other DMA engine access points still use MEMTXATTRS_UNSPECIFIED,
allowing a malicious guest to trigger DMA-to-self-MMIO reentry:
- intel_hda_xfer (line 398): called from the audio timer callback
(hda_codec_xfer -> bus->xfer), so the MemReentrancyGuard does not
fire (engaged_in_io is false outside MMIO dispatch). A guest that
points a BDL entry at the HDA controller's own MMIO BAR can write
audio samples to device registers, triggering whandler side effects
such as starting/stopping streams or injecting codec commands via
CORBWP.
- intel_hda_parse_bdl (line 478): uses pci_dma_read which hardcodes
MEMTXATTRS_UNSPECIFIED. A guest-controlled BDL base address can
point at controller MMIO, allowing the DMA engine to read device
registers as BDL descriptors.
- intel_hda_corb_run (line 333): ldl_le_pci_dma reads the CORB ring
with MEMTXATTRS_UNSPECIFIED, allowing the DMA engine to read
controller MMIO as CORB entries.
Fix all three by passing {.memory = true} explicitly, matching the
fix already applied to intel_hda_response. For intel_hda_parse_bdl,
replace pci_dma_read with pci_dma_rw to pass the controlled attrs.
Fixes: 79fa99831d ("hw/audio/intel-hda: Restrict DMA engine to memories (not MMIO devices)") Reported-by: Haotian Jiang of Tencent Security (Yunding Lab) <jianghaotian.sunday@gmail.com> Signed-off-by: Haotian Jiang <jianghaotian.sunday@gmail.com> Cc: qemu-stable@nongnu.org Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260721060941.2989396-1-jianghaotian.sunday@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Bernhard Beschow [Mon, 20 Jul 2026 20:11:32 +0000 (22:11 +0200)]
hw/sd/sdcard: Fix error case for CMD18
In commit 468fa450a7e0 ("hw/sd: Switch read/write primitive to
buf+len"), `sd_read_byte()` changed its contract to return the read size
rather than the read value (and was renamed to `sd_read_data()`
accordingly). In an error case, however, `sd_read_data()` returns 0 by
means of `dummy_byte` which is the code for the old contract. Moreover,
`sdbus_read_data()` asserts the virtual method `read_data()` (and thus
`sd_read_data()`) to return a non-zero size, i.e. to make progress and
not loop forever. Fix the code to behave like the "DAT read illegal for
command" case.
Fixes: 468fa450a7e0 ("hw/sd: Switch read/write primitive to buf+len") Reviewed-by: Bin Meng <bin.meng@processmission.com> Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260720201133.24796-2-shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Bin Meng [Mon, 20 Jul 2026 12:07:31 +0000 (20:07 +0800)]
hw/net/cadence: Return current Cadence GEM queue pointers
Cadence GEM queue pointer registers are programmed with the descriptor
ring base, but reads return the descriptor currently being accessed.
The model tracked the current positions separately while continuing to
return the configured base.
The Linux macb driver uses the transmit queue pointer when recovering
from a used-buffer interrupt. A stale priority-queue pointer can make
the driver restart DMA before that queue handles its completion
interrupt, causing queue 0 to repeatedly raise TX_USED.
The primary queue has had this mismatch since the initial model.
Priority queue support later copied the same register-read behavior.
A single-queue machine usually handles TX_COMPLETE before TX_USED and
empties the software queue before the restart check, which kept the
issue hidden there.
Return the current RX and TX descriptor positions on queue-pointer reads
and clear those positions on reset.
Fixes: e9f186e514a7 ("cadence_gem: initial version of device model") Fixes: 6710172501be ("cadence_gem: Add queue support") Cc: qemu-stable@nongnu.org Signed-off-by: Bin Meng <bin.meng@processmission.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260720120731.2022475-1-bin.meng@processmission.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
In commit 1ddda5cd364 we meant to set MSSD=3, but due
to a typo we ended setting MSSD=0. Convert the two other
NATJ and MSSP keys to use hexadecimal notation to avoid
similar copy/paste typos.
Cc: qemu-stable@nongnu.org Fixes: 1ddda5cd364 ("AppleSMC device emulation") Reported-by: Matthew Jackson <matthew@pq.io> Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Reviewed-by: Alexander Graf <agraf@csgraf.de> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Message-Id: <20260720115336.75063-1-philmd@oss.qualcomm.com>
When bdrv_snapshot_list() returns a negative error code, sn_tab is
uninitialized. The loop does not execute (since i=0 < negative is
false), but the code falls through to g_free(sn_tab) which frees
an uninitialized pointer.
Fixes: f6baed3d1485 ("replay: implement replay-seek command") Signed-off-by: Marc-Andre Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260719113216.1177594-1-marcandre.lureau@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
The COMPILING_PER_TARGET block uses the abi_ptr type
without including the proper header.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260717232306.378988-2-richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
hw/display/qxl: validate monitors_config heads[] in phys2virt
The qxl_phys2virt() call for guest_monitors_config only validates
sizeof(QXLMonitorsConfig), which covers the fixed header (count and
max_allowed) since commit 8efec0ef8bbc ("hw/display/qxl: Pass requested
buffer size to qxl_phys2virt()"), but not the flexible array member
heads[]. When count == 1, heads[0] is accessed without its memory being
validated, allowing a guest to cause an out-of-bounds read.
Include sizeof(QXLHead) in the size passed to qxl_phys2virt() so that
the first head entry is validated within the guest memory slot, preventing
guest-visible memory reading.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4027 Reported-by: Tristan @TristanInSec Signed-off-by: Marc-Andre Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260715072722.1643289-1-marcandre.lureau@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Peter Maydell [Mon, 29 Jun 2026 16:42:46 +0000 (17:42 +0100)]
net: Correct padding check in qemu_receive_packet()
In qemu_receive_packet() we check to see if we should pad a short
packet. This is doing the wrong test: because this function is used
when the device adds a packet to its own incoming queue (i.e. for
loopback), we should be checking the NetClientState's own do_not_pad
flag, not that for its peer.
We didn't notice this earlier, because at the moment all the real
peers of a network device (i.e. the network backends) do not set
do_not_pad, so net_peer_needs_padding() always returns true except in
the corner case where the network device has no peer at all.
The effect of this is that if a network device has no peer (e.g.
because QEMU was started with -net none or with -nodefaults) then we
can still let through the kind of "guest misprograms the network
device to loopback-transmit a short packet and then we mishandle it
in the receive path" bug like #3043 which commit a01344d9d78 was
trying to fix.
Since the distinction between "we should check nc->do_not_pad"
and "we should check nc->peer->do_not_pad" is a bit subtle, add
enough documentation commentary to make it more obvious.
Cc: qemu-stable@nongnu.org Fixes: a01344d9d78 ("net: pad packets to minimum length in qemu_receive_packet()") Suggested-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Bin Meng <bin.meng@processmission.com>
Message-ID: <20260629164246.2028947-1-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
docs/about/emulation: sharpen the dlcall boundary and its guest requirements
Record the same data model requirement as the plugin: guest_base == 0 is
necessary but not sufficient.
Describe the magic syscall number the way the plugin now does. It has to be a
number the guest ABI does not use and does not reject before the plugin sees
it, rather than merely a high one, so show syscall_num= being used as well.
A library is not turned into thunks, it is left alone and the thunks are
produced for it, so say that instead. Argument marshalling, callbacks and
variadic functions are also what the plugin does not do, and listing them in
its description blurs the boundary it draws. Move them to Lorelei, where they
are pointed at as a reference.
tests/tcg: correct why the magic syscall number is safe here
The comment said 4096 was picked because no ISA in Linux uses it. The same
comment already notes that mips 32 bits numbers from 4000, which makes 4096 its
getpriority.
What actually keeps this test safe is the filter, which matches on the first
argument as well, so a real syscall carrying this number is left alone. Say
that instead.
contrib/plugins/dlcall: correct the syscall number claim, note the data model
The comment claimed every Linux ABI keeps its syscall numbers well below the
minimum, and that the minimum is all N has to satisfy. Neither holds.
MIPS O32 bases its numbering at 4000, so the default 4096 is its getpriority.
Raising N does not rescue it either, because O32 answers numbers its table does
not define with ENOSYS before the filter runs, which leaves no number that is
both free and reachable on that ABI. arm32 bounds N from above too, with ENOSYS
or SIGILL past ARM_NR_BASE. Say all of this, so the number can be chosen with
the target in mind.
guest_base == 0 is not the only requirement either. Host pointers are written
back through the caller's out pointers, so the guest must match the host's
pointer width and endianness. Fold that into the existing warning.
Also assert the two out pointers that lacked it, and point at Lorelei for
argument marshalling, callbacks and variadic functions.
Peter Maydell [Mon, 20 Jul 2026 18:05:30 +0000 (19:05 +0100)]
Revert "target/arm: Build cpu32-system.o as common object"
In c8bea1276c we moved cpu32.c and built it as a common object. The
commit message says "cpu32.c only contains CPU types used in 32-bit
system emulation". However, this is incorrect -- it contains 32-bit
CPU types used in both system and usermode emulation. (The case
where we don't need these CPUs and which we were using ifdefs to
avoid is specifically the AArch64 usermode qemu-aarch64 binary.)
The effect is that qemu-arm lost all the named CPU types except
the M-profile ones (which are in cpu-v7m.c).
Peter Maydell [Mon, 20 Jul 2026 18:05:30 +0000 (19:05 +0100)]
MAINTAINERS: Add soc_dma to OMAP section
The hw/dma/soc_dma.c code appears to have been written with the idea
that it abstracts out DMA transfer operations from the details of a
particular DMA controller device. In practice, it's used only by the
omap_dma code and I would not today recommend trying to use it in any
new DMA device. Add the files to the OMAP section of MAINTAINERS so
that patches can be cc'd to the appropriate places.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260710105907.2570621-10-peter.maydell@linaro.org
Peter Maydell [Mon, 20 Jul 2026 18:05:30 +0000 (19:05 +0100)]
include/hw/arm/omap_dma.h: Move to include/hw/dma
omap_dma.h is the header file for hw/dma/omap_dma.c; it fits better
to put it in include/hw/dma/ to match where we have the .c file.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260710105907.2570621-9-peter.maydell@linaro.org
Now that transfer_mem2mem() uses physical_memory_map(), the
soc_dma_ch_s::paddr field is unused; remove it, and the code that set
it, and the memmap_entry_s::mem.base and the soc_dma_port_add_mem()
phys_base argument that were passing around host pointers to use for
setting paddr.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260710105907.2570621-8-peter.maydell@linaro.org
Peter Maydell [Mon, 20 Jul 2026 18:05:30 +0000 (19:05 +0100)]
hw/dma/soc_dma: Use physical_memory_map() for mem2mem transfers
The soc_dma code has a fastpath for when DMA transfers are from RAM
to RAM. The current implementation of this has the caller of
soc_dma_port_add_mem() pass the underlying host address of the RAM
block that the DMA port is connected to (obtained via
memory_region_get_ram_ptr()). Then the actual transfer function does
a simple memcpy(). This has several problems.
Most importantly, no bounds checking is done on the address and size
passed by the guest, so the memcpy source and destination might be
outside the backing host RAM entirely. Secondly, because the DMA
access is done via this back door, there is no updating of the dirty
region when memory is written this way (there is a TODO comment
in omap_dma.c noting this).
Fix both of these by making the memory to memory transfer function
use physical_memory_map() to get the host addresses for the memory
copy. That function will automatically give us the bounds check that
we want and return a short length if the transfer would run off the
end of the RAM MemoryRegion it starts in. Since the OMAP DMA
documentation states that it's a guest error to misprogram the
addresses so that they fall outside the range that is valid for the
particular DMA port being addressed and that this can result in guest
memory corruption , we don't need to loop for short transfers, but
can simply log them and continue.
Note that we don't need to update addresses or bytecount here in the
transfer function, because when soc_dma_ch_update() selects
transfer_mem2mem it also sets ch->update to 1, which tells the
omap_dma_transfer_setup() code that it is responsible for updating
all the guest visible fields to match "transfer completed".
(We use physical_memory_map() here to match the use of
physical_memory_read() and physical_memory_write() in omap_dma.c;
making the DMA controller use an explicit AddressSpace would be
a separate cleanup task.)
Together with the preceding commits that fixed some integer overflow
problems, this fixes the "guest can provoke a bad memcpy() operation"
reported in issue #3204.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3204 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260710105907.2570621-7-peter.maydell@linaro.org
Peter Maydell [Mon, 20 Jul 2026 18:05:30 +0000 (19:05 +0100)]
hw/dma/soc_dma: dma bytes is uint64_t
The worst case number of DMA bytes that omap_dma will ask us to
transfer is 0xffff * 0xffff * 4 == 0x3fff80004, which is slightly
larger than fits into a uint32_t. Move the byte count to uint64_t,
and adjust code that passes it around to also use uint64_t.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jim MacArthur <jim.macarthur@linaro.org>
Message-id: 20260710105907.2570621-6-peter.maydell@linaro.org
Peter Maydell [Mon, 20 Jul 2026 18:05:30 +0000 (19:05 +0100)]
hw/dma/omap_dma: Be more careful about overflow in transfer setup
In omap_dma_transfer_setup(), the maximum number of elements we can
transfer is 0xffff * 0xffff == 0xfffe0001 (because the max frame
count and max elements per frame are both 65535). However, we store
total element counts in 'int' variables, and use INT_MAX as a "bigger
than any valid value" sentinel, and when performing arithmetic with
the total count of transferred elements we are not careful about
avoiding overflows. Fix these:
- use uint32_t rather than int for the local variables tracking
various element and frame counts
- use UINT_MAX as our sentinel
- calculate new packet, element and frame counter values using
arithmetic on a local uint32_t, rather than doing it in-place
on local variables that are only 'int' because the actual
counter registers are 16 bits
- use 64-bit arithmetic when calculating how much to advance the
source and dest pointers and the total dma->bytes transferred
Note that since soc_dma_ch_s::bytes is only 'int' this can still
overflow; we'll fix that in a subsequent patch.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jim MacArthur <jim.macarthur@linaro.org>
Message-id: 20260710105907.2570621-5-peter.maydell@linaro.org
Peter Maydell [Mon, 20 Jul 2026 18:05:30 +0000 (19:05 +0100)]
hw/dma/soc_dma: Remove union from memmap_entry_s struct
There's only one field in the union inside memmap_entry_s now that
we've removed the soc_dma_port_fifo handling. Simplify by removing
the union.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260710105907.2570621-4-peter.maydell@linaro.org
Peter Maydell [Mon, 20 Jul 2026 18:05:30 +0000 (19:05 +0100)]
hw/dma/soc_dma: Simplify soc_dma_ch_update()
Now we only have "mem" and "other" as soc_dma_port_type values, we
can simplify soc_dma_ch_update(): either both src and dst are mem, in
which case we use transfer_mem2mem and set update to 1 to tell
omap_dma_transfer_setup() to update all the guest-visible
src/dest/count information to indicate a completed transfer; or else
we use the omap_dma_transfer_generic() function, and we set update to
0 to tell omap_dma_transfer_setup() that the transfer function will
be updating the src/dest/count.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260710105907.2570621-3-peter.maydell@linaro.org Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Peter Maydell [Mon, 20 Jul 2026 18:05:30 +0000 (19:05 +0100)]
hw/dma/soc_dma: Remove soc_dma_port_fifo support
Our current single OMAP SoC doesn't call the soc_dma_port_add_fifo(),
soc_dma_port_add_fifo_in() or soc_dma_port_add_fifo_out() functions.
Remove them, plus the soc_dma_port_fifo handling that only those
functions needed.
The motivation for this is that it removes a lot of code that is
careless about the fact that the largest possible DMA transfer is
more bits than will fit into an "int" variable, and which does direct
accesses to host memory pointers into guest backing RAM without doing
bounds checks. Deleting this code means we don't have to audit and
update it.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260710105907.2570621-2-peter.maydell@linaro.org
MTX is always a pair of bits, one for each half of the address space.
Testing it like a boolean is incorrect.
Introduce raw_mte_check, a mirror of the similar mte_check function
that applies when MTX is passed in MTEDESC.
Fixes: 8912ceced815 ("target/arm: load on canonical tag loads ext bits") Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260717161430.37264-1-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Mon, 20 Jul 2026 18:05:30 +0000 (19:05 +0100)]
target/ppc: Remove unused helper_lscbx()
The helper_lscbx() function isn't called anywhere. It used to be
used by the PPC 601 CPU support; we removed that in commit 005b69fdcc
in 2022 but missed this helper function.
Fixes: 005b69fdcc ("target/ppc: Remove PowerPC 601 CPUs") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Message-id: 20260709095056.1803725-1-peter.maydell@linaro.org
Peter Maydell [Mon, 20 Jul 2026 18:05:29 +0000 (19:05 +0100)]
target/arm: GICv5 cpuif: Writes to ICC_APR_EL1 can change IRQ/FIQ
The ICC_APR_EL1 register values change the current running priority,
which we use in our calculations in gic_hppi(). Changing them can
affect whether we have a HPPI, and so the value of the IRQ/FIQ
outputs. We need to trigger an update in the register writefn.
Fixes: 9bd90bddb79 ("target/arm: GICv5 cpuif: Signal IRQ or FIQ") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260714091806.3568281-3-peter.maydell@linaro.org
projects / thirdparty / qemu.git / log
