Stefan Hajnoczi [Tue, 4 Aug 2026 19:35:58 +0000 (15:35 -0400)]
Merge tag 'for-upstream' of https://gitlab.com/kmwolf/qemu into staging
Block layer patches
- Fix missing locking in latency histogram setters
- coroutine: fix lost wakeup in qemu_co_sleep_wake()
- floppy: Fix READ/WRITE/FORMAT/READ ID behaviour with missing medium
- qcow2: Fix crash on closing a read-only image with dirty bit set
- cloop: fix integer overflow in total_sectors calculation
- dmg: Fix out of bounds accesses (CVE-2026-65929, CVE-2026-65928)
- FUSE export: fix regression with O_TRUNC when export is not growable
- iotests: Various small fixes
* tag 'for-upstream' of https://gitlab.com/kmwolf/qemu:
iotests: increase timeouts for tests to 5 minutes
hw/block/fdc: report a missing address mark on an empty drive
hw/block/fdc: select the drive named by the READ ID command
iotests: test O_TRUNC behavior for fuse exports
block/export/fuse: fix regression with O_TRUNC when export is not growable
coroutine: fix lost wakeup in qemu_co_sleep_wake()
iotests/migrate-bitmaps-postcopy-test: replace the timing assertion with a content check
iotests: skip FUSE tests when FUSE is not usable
iotests: run the test pool with the 'fork' start method
qcow2: do not try to clear the dirty bit on a read-only node
dmg: reject inconsistent UDRW chunk sector count and length (CVE-2026-65928)
dmg: refuse to open files with no chunks
dmg: fix out-of-bounds load in search_chunk() (CVE-2026-65929)
tests/unit: add reproducer for BlockAcctStats histogram locking race
block/qapi: take stats->lock when reading BlockAcctStats for query-blockstats
block/accounting: take stats->lock in latency histogram setters
block/cloop: fix integer overflow in total_sectors calculation
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Tue, 4 Aug 2026 19:29:04 +0000 (15:29 -0400)]
Merge tag 'pull-nvme-20260803' of https://gitlab.com/birkelund/qemu into staging
nvme queue
# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCgAdFiEEUigzqnXi3OaiR2bATeGvMW1PDekFAmpxGacACgkQTeGvMW1P
# DekckggApSTjUU3IWkllM1WDy7leeobceXeBKv9Aihlccz3RAjd5pXJTHAMEnpQ4
# /97pUJMzoZN9KB/qMLiYsmS24UngFZo7u7jTY4auPddIBBtLH7W6ojx2fNHnlwul
# 7/84/8M3hQbIy7nIkrMHM7he2hlysRBDvtClTk1kfz5IaXWKfMi50gGbGSFXhAQT
# 2fQz/hQvEnSMHdILfSL4NLAYGu5FDnEM38yX84z/M26ISKYPd12omA9g4Xv+YZL3
# b3ptE+833yAnoUs6ymSxandoL+Fj1GmCC9UZqjmDS7+7txvjQOBl68SgQhidI6F+
# yb4PjPCEv8xE+i/jNoVfAVFhOs64Sg==
# =nPqu
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 03 Aug 2026 18:43:51 EDT
# gpg: using RSA key 522833AA75E2DCE6A24766C04DE1AF316D4F0DE9
# gpg: Good signature from "Klaus Jensen <its@irrelevant.dk>" [unknown]
# gpg: aka "Klaus Jensen <k.jensen@samsung.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: DDCA 4D9C 9EF9 31CC 3468 4272 63D5 6FC5 E55D A838
# Subkey fingerprint: 5228 33AA 75E2 DCE6 A247 66C0 4DE1 AF31 6D4F 0DE9
* tag 'pull-nvme-20260803' of https://gitlab.com/birkelund/qemu:
hw/nvme: fix leak on copy ranges
hw/nvme: cancel inflight requests on controller reset
hw/nvme: factor out nvme_sq_cancel_inflight()
hw/nvme: drop AER requests without aiocb in nvme_del_sq()
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* tag 'pull-vfio-20260802' of https://github.com/legoater/qemu:
vfio/pci: Guard accel_irqchip_begin_route_changes() calls
hw/vfio: Fix liveness check in vfio_connect_kvm_msi_virq()
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
This happens because Docker now pushes out-of-order and the GitLab
Container Registry rejects due to an unknown reference:
https://forum.gitlab.com/t/started-yesterday-docker-push-error-from-registry-blob-unknown-to-registry/134733/5
It is unclear at this point whether GitLab will modify the behavior of
Container Registry or whether Docker will ship a fix.
The current workaround is to disable the provenance attestation that is
involved in this issue. QEMU's CI pipeline container images are used
internally for testing and are not widely distributed. Provenance
attestation can be disabled as there are no external consumers of these
images. Expect to revert this commit in the future when GitLab or Docker
have released their own fixes.
Cc: Alex Bennée <alex.bennee@linaro.org> Cc: Daniel P. Berrangé <berrange@redhat.com> Cc: Thomas Huth <thuth@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20260804165414.480435-1-stefanha@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
qapi/dump: add allowed-by-guest feature to win-dmp
Commit 1c0e259c5a35 ("dump: make win_dump_available() check vmcoreinfo
for a Windows dump header") changed two things in a way that is visible
to QMP clients but not to introspection:
query-dump-guest-memory-capability now lists win-dmp only for a guest
that has published a Windows dump header through the vmcoreinfo device,
and dump-guest-memory, which shares win_dump_available(), rejects the
format otherwise. Before that, both accepted win-dmp on any x86
machine.
A client that wants to select win-dmp automatically therefore cannot
trust the capability query on its own: on an older QEMU it reports
win-dmp for every x86 guest, Linux ones included, where the resulting
dump is useless. libvirt ran into exactly this while picking a format
for on_crash and watchdog triggered dumps, and has no way to tell the
two behaviours apart.
Add an 'allowed-by-guest' feature to the win-dmp member of
DumpGuestMemoryFormat so the fixed behaviour becomes discoverable.
DumpGuestMemoryFormat is reachable from both
query-dump-guest-memory-capability's return type and
dump-guest-memory's arguments, so a single flag covers both halves of
the change. Where the feature is absent, a reported win-dmp says
nothing about the guest, and a client that needs the dump to be
loadable afterwards should fall back to elf.
CC: Eric Blake <eblake@redhat.com> CC: Markus Armbruster <armbru@redhat.com> CC: "Marc-André Lureau" <marcandre.lureau@redhat.com> Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Denis V. Lunev <den@openvz.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260731155001.1204103-1-den@openvz.org>
Bin Guo [Mon, 3 Aug 2026 08:21:58 +0000 (16:21 +0800)]
hw/display/virtio-gpu: Unmap DMA regions on reset
virtio_gpu_reset() freed in-flight commands without unmapping the
DMA regions acquired by virtqueue_pop(). Call virtqueue_detach_element()
before g_free() in both drain loops.
virtio-gpu does not consistently check scanout bounds with wraparound
handling. In the unchecked virgl SET_SCANOUT path, guest dimensions
reach qemu_console_resize(), qemu_create_displaysurface(), and
ultimately qemu_pixman_image_new_shareable(..., &error_abort), so an
invalid rectangle can terminate QEMU. Implement a check with proper
wraparound handling and apply it consistently.
Fixes: 9d9e152136bd ("virtio-gpu: add 3d mode and virgl rendering support.") Fixes: 32db3c63ae11 ("virtio-gpu: Add virtio_gpu_set_scanout_blob") Fixes: 7c092f17ccee ("virtio-gpu: Handle resource blob commands") Fixes: 1dcc6adbc168 ("gfxstream + rutabaga: add initial support for gfxstream") Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260803-scanout-v1-1-c9831dafdab2@rsg.ci.i.u-tokyo.ac.jp>
Ankur Saini [Mon, 3 Aug 2026 17:09:21 +0000 (22:39 +0530)]
virtio-gpu: reject requests with short/truncated control headers
A short control request can leave command data partially initialized.
For the common header, guest-controlled flags can then cause stale fence
metadata to be returned to the guest.
The command fill helpers detect a short copy but only log and return.
For the common header this leaves the request without any completion;
for type-specific commands the caller still completes the request but
reports VIRTIO_GPU_RESP_OK_NODATA, masking the error. Make
VIRTIO_GPU_FILL_CMD() clear the partially copied object and complete the
request with ERR_INVALID_PARAMETER. Make VUGPU_FILL_CMD() report the same
error through the existing vhost-user-gpu dispatcher. This also rejects
truncated type-specific commands.
The vhost-user-gpu common header is copied outside VUGPU_FILL_CMD(), so
clear it and complete the request directly when that copy is short.
hw/display/virtio-gpu: drop redundant node->value NULL checks
QAPI-generated list visitors guarantee that node->value is never NULL:
the input visitor allocates it via g_malloc0() in visit_start_struct(),
and on failure the entire list parse is aborted and freed.
Remove the unnecessary NULL checks from both callsites iterating
g->conf.outputs.
hw/display/virtio-gpu: fix offset wraparound in scanout_blob_to_fb
virtio_gpu_scanout_blob_to_fb() computes the framebuffer offset from
guest-controlled offsets[0], r.x, r.y and stride using uint32_t
arithmetic. When the sum exceeds UINT32_MAX, silent wraparound lets
the guest steer the scanout to an arbitrary in-bounds region of the
blob instead of the intended rectangle.
Compute the offset in uint64_t, reject values exceeding UINT32_MAX
(the width of fb->offset), and only store into fb->offset once both
range checks pass.
("[PATCH] hw/display/virtio-gpu: Remove the bytes_pp field")
vhost-user-gpu: fix integer overflow in buffer allocation
A malicious guest can trigger a heap buffer overflow in the
vhost-user-gpu backend by sending a VIRTIO_GPU_CMD_RESOURCE_CREATE_2D
with large width and height values (e.g. 65537x65537). The allocation
size width * height * 4 silently wraps in uint32_t arithmetic,
resulting in a much smaller allocation than expected. Subsequent
VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D writes past the heap buffer.
The in-tree virtio-gpu device (hw/display/virtio-gpu.c) already handles
this via calc_image_hostmem() with uint64_t arithmetic and an overflow
check. Apply the same approach to the vhost-user-gpu contrib backend:
- Add an overflow check in vugbm_buffer_create() rejecting dimensions
where width * height * 4 exceeds UINT32_MAX
- Promote the size arithmetic to uint64_t in mem_alloc_bo() and
udmabuf_get_size()
- Check the return value of vugbm_buffer_create() in
vg_resource_create_2d(), which was previously ignored
hw/display/vga: fix panning_buf OOB after text/graphics switch
The fields last_width and last_height serve two purposes: the text
renderer counts in characters, the graphics renderer in pixels.
panning_buf reallocation is guarded by geometry-change check, so the
unit mismatch can trick it into thinking nothing changed when the
resolution actually grew.
A guest can trigger this by switching graphics -> text -> graphics:
1. Enter graphics mode with a small width (CR01=0x00, 8 pixels).
The predicate fires and panning_buf is allocated for that width.
2. Switch to text mode with a large width (CR01=0xFF, 256 chars).
The text renderer stores 256 into last_width. The text path
never touches panning_buf.
3. Switch back to graphics with a width that happens to equal 256
in pixels (CR01=0x1F, 32*8 = 256). The predicate sees
256 == 256 and skips the realloc. With horizontal pel panning
enabled, vga_draw_line4() then writes a full 256-pixel scanline
into the buffer still sized for 8 pixels -- a 960-byte heap
overflow on every scanline, every refresh.
Fix it by reallocating unconditionally panning_buf on
vga_draw_graphic().
Fixes: CVE-2026-17516 Fixes: 973a724eb006 ("vga: implement horizontal pel panning in graphics modes")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4085 Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Warisjeet Singh <sinxx198@gmail.com>
[ Marc- André - drop realloc() resize condition & commit message ] Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260728151456.3704099-1-marcandre.lureau@redhat.com>
virtio_gpu_resource_create_blob() stores the guest-controlled blob_size
without checking it against the total size of the iov backing entries.
Since both values are independently guest-controlled, a malicious guest
can set blob_size much larger than the actual iov backing. Subsequent
SET_SCANOUT_BLOB checks bounds against the inflated blob_size, allowing
a pixman surface to be created over the undersized buffer. Any display
refresh then reads past the actual allocation, potentially crashing
QEMU or leaking host memory contents depending on the backing type.
Validate that the iov backing is at least as large as the declared
blob_size in create_blob (when nr_entries > 0, since the spec permits
deferred backing), attach_backing (when attaching to a blob resource),
and the blob migration load path.
Currently we have tests timeout set to 3 minutes, on the basis
that they're generally done in less than a minute. I've hit a
couple of random failures suggesting that's not sufficiently
pessimistic. Increase the timeout to 5 minutes to have a greater
safety net in high load scenarios.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20260623160326.2346255-1-berrange@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Christian Quante [Tue, 14 Jul 2026 16:40:31 +0000 (18:40 +0200)]
hw/block/fdc: report a missing address mark on an empty drive
READ ID on a drive with no medium terminates normally and returns the
made-up sector ID left over from the "Pretend we are spinning" emulation.
The only error path is a data rate mismatch, and media_rate is assigned
solely by pick_geometry(); it is never reset when the medium is removed.
A guest that has just ejected a diskette is therefore told that one is
still present.
READ, WRITE and FORMAT have a related problem: fd_seek() answers 2 both
for "track/head out of range" and for "no medium", so the callers report
ST0 = ABNTERM with ST1 = 0x00 either way. Without ST1.MA the guest cannot
tell an absent diskette from a transient error. Give fd_seek() a return
code of its own for an absent medium, and let both switch statements
report the missing address mark for it.
The comments on the two switches were swapped: fd_seek() answers 2 for a
bad track or head and 3 for a sector past last_sect, but case 2 read
"sect too big" and case 3 "track too big". Both now say what they mean.
This is a behaviour change for FORMAT TRACK on an empty drive as well,
which now answers ST1.MA rather than ST1 = 0x00. None of the guests
tested reaches that path -- DOS gives up during media sensing and never
issues the command -- but it seemed wrong to leave fdctrl_format_sector()
falling through to "default" for a case fd_seek() now reports explicitly.
Failing READ ID does not make guests detect the removal: real hardware
never completes the command on an empty drive, because there are no index
pulses, and OS/2 for one relies on that timeout. It does stop the
controller from claiming a diskette that is not there.
tests/qtest/fdc-test.c starts QEMU with "-device floppy,id=floppy0" and
no medium, and test_read_id asserts a normal termination with a made-up
cylinder 8 / head 1. That contradicts its neighbours
test_no_media_on_start and test_media_change, which state that DSKCHG
signals an absent medium. Insert a medium before READ ID and eject it
afterwards -- the rewritten test passes before and after this change --
and add test_read_id_no_media for the empty drive.
Guests checked, reading and writing, with and without a medium: Linux
2.0.34 and 7.0, PC-DOS 7, IBM DOS 5.02, Windows for Workgroups 3.11 and
OS/2 2.11. None changes behaviour. No version of the Linux floppy driver
from 1.2.13 to master issues READ ID at all -- FD_READID is defined in the
uapi header for FDRAWCMD users and the driver never sends it -- so Linux
detects an empty drive by stepping the head and reading DSKCHG instead.
Buglink: https://gitlab.com/qemu-project/qemu/-/issues/3971 Signed-off-by: Christian Quante <christian@quante.one>
Message-ID: <20260714164031.60551-3-christian@quante.one>
[kwolf: Added fd_seek() comment for new return value 5] Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
fdctrl_handle_readid() does not, so it works on whichever drive happened to
be selected last. A guest that issues READ ID for a drive other than the
one currently selected gets an answer about the wrong one.
It has gone unnoticed because a driver normally writes the DOR to spin up
the motor first, and that write selects the drive as a side effect. The
controller does not require it, though, and the command carries the drive
number for a reason.
Reported-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Christian Quante <christian@quante.one>
Message-ID: <20260714164031.60551-2-christian@quante.one> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The test cases for the blockdev-based export and for the file-based
export with growable=on work before commit a94a1d7699 ("fuse: Manually
process requests (without libfuse)"), then are broken until commit
"block/export/fuse: fix regression with O_TRUNC when export is
growable".
The test case for the blockdev-based export requires passwordless sudo
for losetup and chmod similar to test 108.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Message-ID: <20260702132256.661429-3-f.ebner@proxmox.com>
[kwolf: Catch OSError when probing sudo support] Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Minwoo Im [Wed, 29 Jul 2026 10:34:54 +0000 (19:34 +0900)]
hw/nvme: cancel inflight requests on controller reset
nvme_ctrl_reset() freed every SQ/CQ right after nvme_ns_drain(), which
only waits out requests on a per-namespace BlockBackend. That is safe
as long as the guest first tore down I/O queues gracefully (Delete
I/O SQ/CQ), since nvme_del_sq() already cancels and waits for
anything left on a queue before freeing it.
A reset that happens without that graceful sequence first (e.g. an
abrupt/asynchronous controller reset) can still have commands
inflight on blk_aio_*. Freeing sq/cq before those complete leaves
their completion callbacks (nvme_rw_cb() and friends) to run against
already-freed NvmeRequest/NvmeSQueue/NvmeCQueue memory via
nvme_enqueue_req_completion(), causing a use-after-free/segfault.
Run nvme_sq_cancel_inflight() over every queue in nvme_ctrl_reset()
before the free loops, so no in-flight blk_aio_* callback can fire
after sq/cq memory is freed.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3398
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3883
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4068
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4072 Signed-off-by: Minwoo Im <minwoo.im@samsung.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
Minwoo Im [Wed, 29 Jul 2026 10:34:52 +0000 (19:34 +0900)]
hw/nvme: drop AER requests without aiocb in nvme_del_sq()
nvme_del_sq() asserted r->aiocb was always set when canceling a
queue's inflight requests. A pending Async Event Request has no
aiocb (nvme_aer() parks it without issuing any block I/O), so
deleting a queue with an outstanding AER trips the assert instead of
just dropping the request.
Cc: qemu-stable@nongnu.org Signed-off-by: Minwoo Im <minwoo.im@samsung.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
block/export/fuse: fix regression with O_TRUNC when export is not growable
Before commit a94a1d7699 ("fuse: Manually process requests (without
libfuse)"), the O_TRUNC flag when open()-ing an export would be
ignored. This is because libfuse sets FUSE_CAP_ATOMIC_O_TRUNC, so the
kernel lets user space handle the O_TRUNC flag, which is ignored by
the fuse code for export. After the commit, FUSE_CAP_ATOMIC_O_TRUNC is
not set anymore, so the O_TRUNC flag is handled by the kernel, which
executes a truncate.
For blockdev-based exports, this causes a regression, because opening
with O_TRUNC would previously work, but results in an ENOTSUP after
commit a94a1d7699. For file-based exports, the fact that truncate is
executed can be considered an improvement in general. However, in
combination with growable=off, this still results in a practical
regression in combination with virt-fw-vars, which opens its output
file with O_TRUNC and previously worked with a file-based export with
growable=off. After commit a94a1d7699, the file is truncated upon open
and then cannot grow, meaning virt-fw-vars won't be able to write the
output.
To fix these regressions, while keeping the improved behavior for
file-based exports with growable=on, set the FUSE_CAP_ATOMIC_O_TRUNC
flag again if growable=off.
Cc: qemu-stable@nongnu.org Fixes: a94a1d7699 ("fuse: Manually process requests (without libfuse)") Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Message-ID: <20260702132256.661429-2-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Denis V. Lunev [Wed, 10 Jun 2026 11:58:50 +0000 (13:58 +0200)]
coroutine: fix lost wakeup in qemu_co_sleep_wake()
cache_clean_timer_del_and_wait() cancels the cache-cleaner coroutine
by setting s->cache_clean_interval = 0 and calling qemu_co_sleep_wake()
to cut short its qemu_co_sleep_ns_wakeable(). qemu_co_sleep_wake() is
fire-and-forget: it reads w->to_wake and silently returns when it is
NULL. A sleeper that is between two iterations -- has just released
s->lock but has not yet set w->to_wake inside qemu_co_sleep() -- loses
the wake:
cache_clean_timer_del_and_wait() then blocks on cache_clean_timer_exit
until the original 600 s expiry fires, and qcow2_close() holds BQL the
whole time so the VM stalls behind it.
block_copy_kick() has the same shape. Fix the primitive once instead
of working around it in each caller.
Use a tri-state for QemuCoSleep::to_wake:
NULL - idle
co - sleeper parked
PENDING - wake delivered, no sleeper yet (sticky)
qemu_co_sleep_wake() xchgs PENDING into to_wake: a real sleeper is
woken, NULL/PENDING is left untouched so the wake stays sticky.
qemu_co_sleep() cmpxchg-publishes itself as the sleeper; if a wake
was delivered before it got there or races the publish, the cmpxchg
observes PENDING and returns without yielding. On normal resume
qemu_co_sleep() clears the PENDING the waker left behind so the next
sleep starts clean.
A double-fire (real wake plus timer callback) is harmless: the first
xchg returns the coroutine and wakes it; the second returns PENDING
and is a no-op. Cancellation latency through qemu_co_sleep_wake() is
now bounded by aio_co_wake() rather than by the sleep duration.
Fixes: f86dde9a15 ("qcow2: Fix cache_clean_timer") Signed-off-by: Denis V. Lunev <den@openvz.org> Cc: Hanna Czenczek <hreitz@redhat.com> Cc: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20260610115850.2410566-2-den@openvz.org> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
iotests/migrate-bitmaps-postcopy-test: replace the timing assertion with a content check
`downtime * 10 < postcopy_time` was an unnormalized wall-clock
heuristic (commit e80a4150a5) that fails on fast hosts, where the
bitmap payload now transfers in under a second.
Check the actual invariant instead: right after RESUME, bitmap0's
content hash on the destination must not yet match the fully
migrated value. Throttle max-bandwidth first, since all-zero chunks
skip the payload write and would otherwise let a fast host finish
the transfer before the check runs.
Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Kevin Wolf <kwolf@redhat.com> CC: Hanna Reitz <hreitz@redhat.com> CC: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-ID: <20260715103451.1930909-4-den@openvz.org> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
file-io-error, fuse-allow-other and fuse-mmap-shared skip only when
FUSE is not compiled in. When FUSE is built in but unusable at run
time (no /dev/fuse access, fusermount lacking permissions), the
export fails to mount with "Failed to mount FUSE session to export"
and the tests report a spurious failure instead of skipping, like
NBD tests already do for missing NBD support.
Add _notrun_on_fuse_error() to common.rc and use it in the shell
tests. fuse-mmap-shared is Python, so it gets an equivalent inline
check.
Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Kevin Wolf <kwolf@redhat.com> CC: Hanna Reitz <hreitz@redhat.com>
Message-ID: <20260715103451.1930909-3-den@openvz.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
iotests: run the test pool with the 'fork' start method
run_tests_pool() shares the runner via the class attribute
TestRunner.shared_self, relying on worker processes to inherit it.
That only works with the 'fork' start method. Python 3.14 switched
the Linux default to 'forkserver', so workers see shared_self as
None and parallel runs abort with:
assert runner is not None
AssertionError
Only reproduces with Python 3.14+ and 'check -jN' (N > 1); meson
runs one test per process and never calls run_tests_pool(), so CI
is unaffected.
Request get_context('fork') explicitly; it is available on all
supported Python versions and a no-op before 3.14.
Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Kevin Wolf <kwolf@redhat.com> CC: Hanna Reitz <hreitz@redhat.com>
Message-ID: <20260715103451.1930909-2-den@openvz.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
qcow2: do not try to clear the dirty bit on a read-only node
qcow2_do_close() -> qcow2_inactivate() clears the dirty bit with a
plain write to bs->file, unconditionally. A read-only node can still
be dirty, inherited from an earlier writable session, and that write
then hits a missing BLK_PERM_WRITE and asserts in
bdrv_co_write_req_prepare() (block/io.c) on an entirely ordinary
close -- closing is expected, the dirty bit on a read-only node
is not.
Skip the clear for read-only nodes, same as read access already does.
Any other still-dirty node keeps the unguarded write: it is expected
to hold write permission, and a missing one there is a bug worth
seeing.
Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Kevin Wolf <kwolf@redhat.com> CC: Hanna Reitz <hreitz@redhat.com>
Message-ID: <20260716153552.3376009-1-den@openvz.org> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Stefan Hajnoczi [Thu, 23 Jul 2026 14:45:19 +0000 (10:45 -0400)]
dmg: reject inconsistent UDRW chunk sector count and length (CVE-2026-65928)
The chunk metadata contains both:
- Sector count: number of 512-byte sectors in the virtual disk
- Length: number of bytes in the image file
The UDRW chunk type indicates uncompressed data that can be accessed
directly. The code is missing input validation to verify that sector
count is consistent with length.
If sector count is larger than length, then read requests can access
beyond the end of the s->uncompressed_chunk buffer. This is an
out-of-bounds heap access that could lead to a crash or an information
leak.
While we're at it, also zero the end of the last sector when length is
unaligned. This prevents information leaks from the
s->uncompressed_chunk buffer.
Fixes: CVE-2026-65928
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3846 Reported-by: boy juju <agx1657748706@gmail.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20260723144519.364701-4-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Stefan Hajnoczi [Thu, 23 Jul 2026 14:45:18 +0000 (10:45 -0400)]
dmg: refuse to open files with no chunks
The dmg block driver expects the disk image file to contain at least one
chunk. Refuse to open such files. This ensures that dmg block driver
state always has non-NULL s->sectors[] and related fields.
Note that the previous commit fixed the only known way to trigger a
crash. This patch is just for defense - let's avoid opening the file and
having NULL pointers in dmg block driver state.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4021 Reported-by: Tristan Madani <tristan@talencesecurity.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20260723144519.364701-3-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Stefan Hajnoczi [Thu, 23 Jul 2026 14:45:17 +0000 (10:45 -0400)]
dmg: fix out-of-bounds load in search_chunk() (CVE-2026-65929)
The binary search in search_chunk() uses s->n_chunks as the (inclusive)
upper bound. Chunk indices are in the right-open interval [0,
s->n_chunks) so it is wrong to search all the way up to s->n_chunks
rather than s->n_chunks - 1.
The worst case security scenario I can see is convincing a victim to
hotplug a malicious DMG file to a running guest, potentially causing
QEMU to crash when loading from memory beyond the end of s->sectors[] or
s->sectorscounts[]. This could be a denial of service.
Fixes: CVE-2026-65929
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3844 Reported-by: boy juju <agx1657748706@gmail.com> Reported-by: Tristan Madani <tristan@talencesecurity.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20260723144519.364701-2-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
tests/unit: add reproducer for BlockAcctStats histogram locking race
block_latency_histogram_set() and block_latency_histograms_clear()
replace BlockLatencyHistogram's nbins/boundaries/bins without taking
stats->lock, while block_account_one_io() reads those same fields
under that lock from whatever iothread completes the I/O.
Add a test that races two real threads against
block_latency_histogram_set() and
block_acct_start()/block_acct_done() on the same BlockAcctStats.
Applied here it passes, since the previous two commits already take
the lock; reverting them locally reproduces the abort this series
fixes, in about a second.
Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Kevin Wolf <kwolf@redhat.com> CC: Hanna Reitz <hreitz@redhat.com> CC: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> CC: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Message-ID: <20260724111311.4086859-4-den@openvz.org> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
block/qapi: take stats->lock when reading BlockAcctStats for query-blockstats
bdrv_query_blk_stats() reads BlockAcctStats's counters, latency
histogram, and per-interval TimedAverage stats without stats->lock,
while block_account_one_io() updates the same fields under that lock
from an iothread. timed_average_min()/max()/avg() make this worse
than a stale read: they call check_expirations(), which can reset a
window's sum/count/min/max -- a write, not just a read -- so this is
a genuine race with a concurrent writer, not merely a slower reader
like the scalar counters.
Take stats->lock for the whole call, both to close the race and to
make the returned snapshot internally consistent (previously each
field could reflect a different instant relative to concurrent
updates).
block_acct_queue_depth() used to take the lock itself on every call;
since bdrv_query_blk_stats() is its only caller and now already holds
the lock, that would self-deadlock. Make it require the caller to
hold stats->lock instead (documented and asserted).
Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Kevin Wolf <kwolf@redhat.com> CC: Hanna Reitz <hreitz@redhat.com> CC: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> CC: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Message-ID: <20260724111311.4086859-3-den@openvz.org> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
block/accounting: take stats->lock in latency histogram setters
block_latency_histogram_set() and block_latency_histograms_clear()
replace BlockLatencyHistogram's nbins/boundaries/bins without taking
stats->lock, while block_account_one_io() reads those same fields
under that lock from whatever iothread completes the I/O. The result
is usual use-after-free and qemu crash.
Take stats->lock in both setters, matching the lock already held by
the reader.
Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Kevin Wolf <kwolf@redhat.com> CC: Hanna Reitz <hreitz@redhat.com> CC: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> CC: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Message-ID: <20260724111311.4086859-2-den@openvz.org> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
block/cloop: fix integer overflow in total_sectors calculation
The total_sectors is computed as n_blocks * sectors_per_block where
both operands are uint32_t. The multiplication is performed in 32-bit
arithmetic and can overflow when the product exceeds UINT32_MAX,
producing a value much smaller than the true image size. The result
is assigned to int64_t total_sectors but the 32-bit multiplication
has already wrapped around, and the zero-extension to 64-bit does
not recover the correct value.
This causes the block layer to reject valid I/O requests (DoS) when
the reported total_sectors is smaller than the actual image.
Use 64-bit arithmetic by casting one operand to uint64_t so the
multiplication is performed in 64-bit precision.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3972 Signed-off-by: Ma Like <malike@kylinos.cn>
Message-ID: <20260713031750.58448-1-malike@kylinos.cn> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Since commit 49b2dcbd2422 ("accel/accel-irq: add generic
begin_route_changes"), accel_irqchip_begin_route_changes() aborts when
no accelerator irqchip is available. This causes a fatal error when
running VFIO passthrough devices under TCG emulation:
qemu-system-aarch64: can't initiate route change, no accel irqchip available
The previous kvm_irqchip_begin_route_changes() was a simple inline
that did not have a fatal path. The VFIO code already handles the
absence of KVM MSI routing gracefully by falling back to userspace
handling, but the new generic function aborts before that fallback
can take effect.
Guard the call sites in hw/vfio/pci.c with
accel_msi_via_irqfd_enabled() so that route changes are only
initiated when an accelerator irqchip is actually present.
hw/vfio: Fix liveness check in vfio_connect_kvm_msi_virq()
While working on savevm/loadvm for a new vfio device, I encountered the
crash below. Since vfio_connect_kvm_msi_virq() didn't check the ->use flag
for the vector, it would pass an unused vector down to
vfio_cpr_load_vector_fd() which would crash.
Fix this by checking the ->use flag along with the virq number to detect
whether a vector is valid or not.
Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
0x0000555555a891ef in vfio_cpr_load_vector_fd (vdev=vdev@entry=0x0,
name=name@entry=0x555555eeb27e "kvm_interrupt", nr=nr@entry=1) at ../hw/vfio/cpr.c:44
44 g_autofree char *fdname = STRDUP_VECTOR_FD_NAME(vdev, name);
(gdb) bt
#0 0x0000555555a891ef in vfio_cpr_load_vector_fd
(vdev=vdev@entry=0x0, name=name@entry=0x555555eeb27e "kvm_interrupt", nr=nr@entry=1)
at ../hw/vfio/cpr.c:44
#1 0x0000555555ce64a1 in vfio_notifier_init
(vdev=0x0, e=e@entry=0x5555586971b4, name=name@entry=0x555555eeb27e "kvm_interrupt", nr=nr@entry=1, errp=errp@entry=0x0) at ../hw/vfio/pci.c:79
#2 0x0000555555ce721e in vfio_connect_kvm_msi_virq (vector=0x5555586971a8, nr=nr@entry=1)
at ../hw/vfio/pci.c:601
#3 0x0000555555cea5a5 in vfio_connect_kvm_msi_virq (nr=1, vector=<optimized out>)
at ../hw/vfio/pci.c:597
#4 vfio_pci_commit_kvm_msi_virq_batch (vdev=0x55555906de40) at ../hw/vfio/pci.c:822
#5 0x0000555555cea9f2 in vfio_msix_enable (vdev=vdev@entry=0x55555906de40) at ../hw/vfio/pci.c:850
#6 0x0000555555ceb152 in vfio_pci_load_config (vbasedev=0x55555906e900, f=<optimized out>)
at ../hw/vfio/pci.c:3088
#7 0x0000555555a8c765 in vfio_load_device_config_state (f=0x5555574a43d0, opaque=0x55555906e900)
at ../hw/vfio/migration.c:278
#8 0x0000555555b3a522 in vmstate_load
(f=f@entry=0x5555574a43d0, se=se@entry=0x5555591edd40, errp=errp@entry=0x7fffffffe130)
at ../migration/savevm.c:971
#9 0x0000555555b3ab1a in qemu_loadvm_section_start_full
(f=f@entry=0x5555574a43d0, type=type@entry=4 '\004', errp=errp@entry=0x7fffffffe130)
at ../migration/savevm.c:2654
#10 0x0000555555b3e1ee in qemu_loadvm_state_main
(f=f@entry=0x5555574a43d0, mis=mis@entry=0x5555571de5a0, errp=0x7fffffffe130,
errp@entry=0x555557157c10 <error_fatal>) at ../migration/savevm.c:2973
#11 0x0000555555b3f7b7 in qemu_loadvm_state
(f=f@entry=0x5555574a43d0, errp=errp@entry=0x555557157c10 <error_fatal>)
at ../migration/savevm.c:3058
#12 0x0000555555b40863 in load_snapshot
(name=0x7fffffffecc9 "foo", vmstate=vmstate@entry=0x0, has_devices=has_devices@entry=false, devices=devices@entry=0x0, errp=errp@entry=0x555557157c10 <error_fatal>) at ../migration/savevm.c:3452
#13 0x0000555555adc211 in qmp_x_exit_preconfig (errp=0x555557157c10 <error_fatal>) at ../system/vl.c:2817
#14 qmp_x_exit_preconfig (errp=0x555557157c10 <error_fatal>) at ../system/vl.c:2802
#15 0x0000555555adf8ed in qemu_init (argc=<optimized out>, argv=<optimized out>) at ../system/vl.c:3849
#16 0x00005555558903fd in main (argc=<optimized out>, argv=<optimized out>) at ../system/main.c:71
Removing the call to gen_compute_eflags meant we no longer
updated cc_op after computing EFLAGS.
Cc: qemu-stable@nongnu.org Fixes: da7649c6aeef ("target/i386/tcg: do not compute all flags for SAHF")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3537 Tested-by: Christian Quante <christian@quante.one> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
* tag 'pull-target-arm-20260731' of https://gitlab.com/pm215/qemu:
target/arm: Remove stale comment about WFE/SEV implementation
target/arm: Make YIELD, WFI and WFE be NOPs on pre-v6K
target/arm: Don't NOP the SEV insn on v6K CPUs
target/arm: Fix b16b16 feature test for SME2 BFCLAMP, BFMAX, BFMIN
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Peter Maydell [Fri, 31 Jul 2026 10:24:27 +0000 (11:24 +0100)]
target/arm: Remove stale comment about WFE/SEV implementation
We forgot to remove a comment about WFE/SEV only being implemented
for M-profile when we added the A-profile support for this; delete
the stale text.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260728111629.1705308-4-peter.maydell@linaro.org
Peter Maydell [Fri, 31 Jul 2026 10:24:27 +0000 (11:24 +0100)]
target/arm: Make YIELD, WFI and WFE be NOPs on pre-v6K
The YIELD, WFI and WFE instructions are in the NOP hint space, and
were only defined to actual non-NOP instructions starting in the v6K
architecture; they are also present for all M-profile architecture
versions.
We never did check the architecture version before making these
instructions have their special behaviour. Mostly this has not been
a problem because a guest won't execute one of these insns unless it
is prepared for it to have its usual effect, and because we
implemented SEV and WFE as NOPs anyway.
Now we have implemented SEV and WFE to be more than just NOPs, it's
important that we have the same condition on the SEV as the WFE, so
that we either NOP both or else implement both. A guest probably
won't try to use SEV/WFE on CPUs that don't implement them, but it is
valid for it to do that and rely on them both being NOPs (and so a
WFE-loop falls back to a pure busy-wait loop).
Add the "only if M profile or v6K or better" check to YIELD, WFE and
WFI. This means that all the insns in the NOP-hint space for A32,
T32 and T16 have a correct feature check.
Fixes: 60e7ee5bb7cd ("target/arm: implements SEV/SEVL for all modes") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260728111629.1705308-3-peter.maydell@linaro.org
Peter Maydell [Fri, 31 Jul 2026 10:24:27 +0000 (11:24 +0100)]
target/arm: Don't NOP the SEV insn on v6K CPUs
When we implememented SEV to do something on A-profile rather than
being a nop, we got the condition slightly wrong, and made it only
effective from v7. In fact the instruction's Arm encoding has
non-NOP behaviour from ARMv6K.
The effect is that a kernel boot may hang on a v6K CPU like the
ARM11MPCore.
(This wouldn't have been so noticeable if we feature checked the WFE
instruction, and had made the same mistake for the condition on both
instructions. But we never have done the feature checks that we
ought on WFE, so the mistake on SEV meant that we showed the 11mpcore
guest a WFE that did something and a SEV that was a NOP.)
The v7A Arm ARM is not entirely clear about whether v6K has the Thumb
SEV encoding or not: it says "ARMv7 (executes as NOP in ARMv6T2)",
leaving v6K not stated. The 11MPCore TRM says it has at least WFI in
both Arm and Thumb, and the v7A Arm ARM uses the same condition text
for WFI, so I make the assumption that WFI, WFE, and SEV all get
their functionality for both Thumb and Arm in v6K. It's possible
that this differed between v6K CPUs -- the 1176 TRM says it has the
v6K STREXD/STREXH/STREXB etc, but the WFI is the old-style cp15 one.
Keeping the condition check the same for both Thumb and Arm encodings
is the conservative choice: if guests try to execute the Thumb SEV
insn it will be because they want SEV, not because they want a NOP.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4044 Fixes: 60e7ee5bb7cd ("target/arm: implements SEV/SEVL for all modes") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260728111629.1705308-2-peter.maydell@linaro.org
Stefan Hajnoczi [Thu, 30 Jul 2026 14:52:25 +0000 (10:52 -0400)]
Merge tag 'linux-user-pull-request' of https://github.com/hdeller/qemu-hppa into staging
linux-user patches
Three linux-user patches, one aarch64 shadow stack fix
and two fixes for members of the target_msqid_ds struct.
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCampphwAKCRD3ErUQojoP
# X7D4AQDACw5DckBlNDY+3pDWE6/vYLFx+GJXgZKpF7nVf+/VugEA7QggRBMc82ch
# 5g4vDD+y8o6EBPHT+/vD8Ip2uYcDqgQ=
# =azKH
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 29 Jul 2026 16:58:47 EDT
# gpg: using EDDSA key BCE9123E1AD29F07C049BBDEF712B510A23A0F5F
# gpg: Good signature from "Helge Deller <deller@gmx.de>" [unknown]
# gpg: aka "Helge Deller <deller@kernel.org>" [unknown]
# gpg: aka "Helge Deller <deller@debian.org>" [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: 4544 8228 2CD9 10DB EF3D 25F8 3E5F 3D04 A7A2 4603
# Subkey fingerprint: BCE9 123E 1AD2 9F07 C049 BBDE F712 B510 A23A 0F5F
* tag 'linux-user-pull-request' of https://github.com/hdeller/qemu-hppa:
linux-user/aarch64: Fix SHADOW_STACK_SET_TOKEN
linux-user: fix incorrect msg_l[sr]pid members of target_msqid_ds
linux-user: Fix msqid_ds struct wrt 32-bit big endian architectures
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
linux-user: fix incorrect msg_l[sr]pid members of target_msqid_ds
The members are declared as __kernel_pid_t in Linux UAPI headers.
Analogous members in struct target_shmid_ds (shm_[cl]pid) are also
declared as abi_int.
linux-user: Fix msqid_ds struct wrt 32-bit big endian architectures
Make sure that the time entries (msg_stime, msg_rtime and msg_ctime)
are defined as 64-bit time_t values, since the userspace may access
the whole 64-bit value. By this change we fix the word ordering for
32-bit big endian architectures as well.
Stefan Hajnoczi [Tue, 28 Jul 2026 21:00:42 +0000 (17:00 -0400)]
Merge tag 'pull-parallels-2026-07-28' of https://gitlab.com/dlunev/qemu into staging
Parallels block driver patches
- fix a reachable assert()/process abort on a crafted image with an
inconsistent BAT vs. advertised disk size (GitLab #3804)
- fix related integer overflows capping the format's usable catalog
size below its documented maximum
- reject BAT entries pointing outside the data area in either
direction
- harden the dirty-bitmap extension loader against a reachable
abort and an unsafe allocator
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEC66qh9MCCtwRUOUfXgdxtstmbKsFAmpoy6UACgkQXgdxtstm
# bKvDcA/7Bis1fqsgvsLDiLfxPmNXmaA6JwsHLCgcqnBtrlfucLpDghsE6Nr6Lthb
# zgkYuWrNRtnIwbGEe4oW4jEukLb8k6hyUlwfQvIQik3rV0nnv1G4ewQMH7TmLKX+
# xqFSK+TUpW5bQMphH3yOM2IShgytCXirPSZLfz1GY76eOSWcab/SgzPhANTf6bG3
# o3eVZML9GrPDeDx3MuNdqfup+pX081xOM9l3Ub1hn8YRVvvZiaEmaw4HvT66Qnul
# XL9/biNii0r7b4uITOj6Pvvft7W5yW5d+VL9P5hiidDvhwpC6CAjpu7/qScA3ZH2
# v3MWnXwOEPLnmUE43ZR/8Vb07bHdSHuVLGgD7RPdmWGMMM2pzaCpbMRkdr9ABY5k
# IdPISsijSeGt4Vi9hhXsBiL2tzBJ0w8w+x6o7YNM8RkHzKm7APWwKssJ6kIyQC7g
# ImNgSVRbXBf+4bAD2MUiy3MOfkJ8li9oCXuFaC9fUx5Y4Y4DZdAmARjccUNwttMa
# oixwlypndqJsXspikAsqQqMqA/cVAUd+rec2jDVx3W2nhZsV3KsMu8hD4jYeQkTx
# CRi7owYuA0Z+eNLVvdsji292GcQKP7jcriM1gsSbhyyYDJUT3FHtpNKUxWOr1nFz
# YWj8xSPy5rCpO9CheSXWtk7v/GKpq3riQ48KBbnfArBNxPBPNDY=
# =aCB6
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 28 Jul 2026 11:32:53 EDT
# gpg: using RSA key 0BAEAA87D3020ADC1150E51F5E0771B6CB666CAB
# gpg: Good signature from "Denis V. Lunev <den@openvz.org>" [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: 0BAE AA87 D302 0ADC 1150 E51F 5E07 71B6 CB66 6CAB
* tag 'pull-parallels-2026-07-28' of https://gitlab.com/dlunev/qemu:
MAINTAINERS: update parallels tree location
parallels: validate BAT capacity against advertised disk size
parallels: avoid fatal abort on large bitmap L1 table
parallels: skip loading a genuinely empty bitmap L1 table
parallels: validate bitmap L1 table size before allocating it
parallels: reject BAT entries pointing outside backed storage
parallels: fix bat_entries overflow in image creation
parallels: read header/BAT table in bounded chunks
parallels: fix integer overflow in header size calculation
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Klaus Jensen [Tue, 28 Jul 2026 09:42:29 +0000 (11:42 +0200)]
hw/nvme: fix unintentional integer overflow in shift
Fix potentially overflowing shift operation.
Cc: qemu-stable@nongnu.org Suggested-by: Peter Maydell <peter.maydell@linaro.org> Suggested-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Resolves: Coverity CID 1663674 Fixes: ec917cd49918 ("hw/nvme: fix FDP set FDP events") Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
The NVMe specification allows a controller with multiple namespaces to
use different LBA formats per namespace. One implication of this is that
the destination namespace may have a metadata area for PI, but the
source does not. In that case, the controller shall generate the
protection information, but the bounce buffer is erroneously allocated
without space for that, causing a buffer overflow.
Fix the allocation.
Cc: qemu-stable@nongnu.org Fixes: d522aef88d42 ("hw/nvme: add cross namespace copy support")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3387 Reported-by: Jihe Wang <wangjihe.mail@gmail.com> Reported-by: boy juju <agx1657748706@gmail.com> Reported-by: contact <contact@xchglabs.com> Reported-by: david korczynski <david@adalogics.com> Reported-by: Brian Chastain (off_by_one / Curious-Keeper) <brian@scalingsuccess.io> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
Daniel Paziyski [Sun, 26 Jul 2026 18:30:08 +0000 (20:30 +0200)]
hw/nvme: fix assertion failure on subregion removal
When a controller is created with a MSI-X exclusive BAR, the bar0 memory region
is not used at all, and so, the iomem region is not added as a subregion of it.
However, when removing a NVMe controller, the iomem region is unconditionally
removed as a subregion of bar0, causing an assertion failure. Remove the iomem
memory region as a subregion of bar0 only if not using a MSI-X exclusive BAR.
Let's use GPtrArray to build a list of blocker features and then
g_strjoinv() to build a final comma-delimited string.
While previous approach was technically correct, it is fragile
(because we need to take care of static buffer size choice) and
Coverity dislikes it too.
Note, that we use g_ptr_array_new() to allocate array which means
that GDestroyNotify callback is not set, so we can pass pointers to
a static memory like g_ptr_array_add(..., (gpointer) "SR-IOV") without
any problems as there won't be any attempt to free that memory.
Resolves: Coverity CID 1663673 Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@futurfusion.io> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Klaus Jensen <k.jensen@samsung.com>
[k.jensen: change cast from gpointer to void ptr] Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
parallels: validate BAT capacity against advertised disk size
parallels_open() copied nb_sectors, tracks, and bat_entries from the
image header without checking that the BAT actually covers the
advertised virtual disk size. An image whose header claims more
sectors than its BAT covers passes the generic block-layer bounds
check on open. A write into the gap between BAT coverage and the
advertised size then reaches allocate_clusters(), whose internal
assert(idx < s->bat_size && idx + to_allocate <= s->bat_size) aborts
the process instead of returning a normal I/O error.
Reject such images at open time by requiring
bat_size * tracks >= total_sectors, matching the invariant that
allocate_clusters() already assumes.
Reported-by: Feifan Qian <bea1e@proton.me>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3804 Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Thomas Huth <thuth@redhat.com> CC: Stefan Hajnoczi <stefanha@redhat.com>
parallels: skip loading a genuinely empty bitmap L1 table
parallels_load_bitmap_data() unconditionally calls
bdrv_dirty_bitmap_deserialize_finish() even when there is nothing to
deserialize, which hits an assertion in hbitmap
(hbitmap_iter_init: 'pos < hb->size') when the bitmap itself has
zero size, i.e. the disk is a zero-sector image.
Skip allocating, populating and loading the L1 table entirely when
l1_size == 0. This is safe only because the previous commit already
guarantees l1_size == 0 exclusively means the disk has 0 size.
Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Thomas Huth <thuth@redhat.com> CC: Stefan Hajnoczi <stefanha@redhat.com>
parallels: validate bitmap L1 table size before allocating it
parallels_load_bitmap() allocated the L1 table sized directly from
the untrusted l1_size field, only cross-checking it against the
bitmap's actual size after the allocation and the L1 table copy had
already happened.
Compute the expected size and reject a mismatch before touching the
allocator, instead of after.
Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Thomas Huth <thuth@redhat.com> CC: Stefan Hajnoczi <stefanha@redhat.com>
parallels: reject BAT entries pointing outside backed storage
parallels_open()'s BAT scan and parallels_check_outside_image() only
checked entries against the file's upper end, matching just half of
what docs/interop/parallels.rst requires: an entry's offset must be
both >= data_start and < the file size. An entry below data_start
resolves into the header/BAT region itself, corrupting metadata on
write or losing the write silently on a partial overlap, and neither
qemu-img check nor the open-time scan ever caught it.
Check both bounds everywhere a BAT entry is resolved to a host
offset: seek_to_sector(), the open-time scan (without letting a bad
entry inflate data_end), and parallels_check_outside_image().
Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Thomas Huth <thuth@redhat.com> CC: Stefan Hajnoczi <stefanha@redhat.com>
parallels: fix bat_entries overflow in image creation
parallels_co_create() computed the BAT entry count directly into a
uint32_t, wrapping silently to zero at exactly 2^32 entries and
writing out a header whose BAT no longer matches its advertised
size. Compute it in an int64_t first and reject it once it no longer
fits, matching the cap parallels_open() already enforces. Also
reject cluster-size 0, and clamp header.cylinders instead of letting
it truncate the same way.
Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Thomas Huth <thuth@redhat.com> CC: Stefan Hajnoczi <stefanha@redhat.com>
parallels: read header/BAT table in bounded chunks
parallels_open() read the whole header+BAT table with a single
bdrv_pread() call sized s->header_size. For an image whose catalog
approaches the "Catalog too large" bound (INT_MAX / sizeof(uint32_t)
entries), that size approaches BDRV_REQUEST_MAX_BYTES, and the block
layer legitimately refuses a single request that large, so the image
failed to open with a generic I/O error even though the catalog size
itself is within the format's documented limit.
Read the header and BAT table in fixed-size chunks instead, so the
maximum catalog size parallels_open() can actually address matches
the bound it already enforces, independent of the file's block-layer
alignment requirements.
Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Thomas Huth <thuth@redhat.com> CC: Stefan Hajnoczi <stefanha@redhat.com>
* tag 'hw-misc-20260728' of https://github.com/philmd/qemu:
tests/functional/ppc: skip remote interrupts test if -net user not built
target/sparc: set reg window data structures currently after vmstate load
hw/net/igb: recalculate rx_desc_len on migration load
hw/net/e1000e: recalculate rx_desc_len on migration load
hw/sd/sdhci: Extract uSDHC-specific quirk
hw/net/xilinx_axienet: Don't write checksums off end of packet
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Tue, 28 Jul 2026 14:03:54 +0000 (10:03 -0400)]
Merge tag 'linux-user-pull-request' of https://github.com/hdeller/qemu-hppa into staging
linux-user patches
Enable fsmount() syscalls, fix build with Linux 7.2 kernel headers and
allow full 32-bit address space on sh4.
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCamhzJgAKCRD3ErUQojoP
# X2WUAP9UOBDozOx0rqpDRDM1ktMQdp3zaUT+wJIyLojcNZcj8QD/aaImcmjuU4h9
# Slgtdh5qtIUJynvOemumwW442Ftd3AQ=
# =RFH+
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 28 Jul 2026 05:15:18 EDT
# gpg: using EDDSA key BCE9123E1AD29F07C049BBDEF712B510A23A0F5F
# gpg: Good signature from "Helge Deller <deller@gmx.de>" [unknown]
# gpg: aka "Helge Deller <deller@kernel.org>" [unknown]
# gpg: aka "Helge Deller <deller@debian.org>" [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: 4544 8228 2CD9 10DB EF3D 25F8 3E5F 3D04 A7A2 4603
# Subkey fingerprint: BCE9 123E 1AD2 9F07 C049 BBDE F712 B510 A23A 0F5F
* tag 'linux-user-pull-request' of https://github.com/hdeller/qemu-hppa:
linux-user/sh4: allow full 32-bit address space
linux-user: fix guards for the fsmount(2) syscall series
linux-user: Guard local FUTEX_CMD_MASK definition
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Peter Maydell [Mon, 6 Jul 2026 17:33:24 +0000 (18:33 +0100)]
hw/display/exynos4210_fimd: Clamp windows to screen size
In exynos4210_fimd_update(), we iterate through the enabled windows,
blitting them to the screen. We assume here that the guest has not
programmed the window's coordinates to be outside the overall LCD
screen resulation, but we never check this. This can result in the
guest being able to cause us to access outside our allocated
framebuffer backing memory.
Since all the coordinates here are unsigned, they can't be off
the left/top side of the screen, only the bottom/right. If
the top left corner of the window is out of bounds, the whole
window is invisible and we can skip it. If the bottom right
corner is out of bounds, we clamp it to the screen size so that
we only draw the visible part.
Peter Maydell [Mon, 6 Jul 2026 17:33:23 +0000 (18:33 +0100)]
hw/display/exynos4210_fimd: Pass width to draw_line functions
The draw_line functions currently assume the width of the line they
need to draw is w->rightbot_x - w->lefttop_x + 1, i.e. the full
width of the guest-programmed window. We want to be able to clamp
this to the overall screen size, which we can calculate in the
calling function.
Refactor to do this calculation in the caller and pass the
width as an argument to the draw_line functions.
Stable CC because this is a prerequisite for an upcoming bugfix
commit.
Peter Maydell [Mon, 6 Jul 2026 17:33:22 +0000 (18:33 +0100)]
hw/display/exynos4210_fimd: Factor out finding screen width/height
Currently we hard-code the expressions for getting the global screen
width and height out of the VIDTCON2 register where we need them.
Use functions instead. Make the global_width variable in
exynos4210_fimd_update() uint32_t for consistency. (The values are
clamped to well below INT_MAX, so there is no overflow risk here.)
Stable CC because this is a prerequisite for an upcoming bugfix
commit.
The Clock Stretch Timeout (CLKT) register for the BCM2835 I2C
controller is actually located at offset 0x1c, not 0x20.
Update the BCM2835_I2C_CLKT macro to match the hardware
specification.
Since QEMU's implementation ignores whatever value the guest
writes to this register, and Linux only writes to CLKT and
doesn't read it back, the main effect of this fix is to
avoid an incorrect GUEST_ERROR log.
Cc: qemu-stable@nongnu.org Fixes: 9cf3bc65afdb63 ("hw/i2c: Implement Broadcom Serial Controller (BSC)") Signed-off-by: botszhuang <botszhuang@gmail.com> Tested-by: Nick Huang <sef1548@gmail.com>
Message-id: 20260724124220.24152-1-22925483+botszhuang@users.noreply.github.com
[PMM: removed commit message paragraph about effects which I think
is incorrect, substituted a different one] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Simon Xu [Fri, 24 Jul 2026 16:09:43 +0000 (11:09 -0500)]
hw/misc/mps2-scc.c: fix scc_partno field width
Increase the extract32 length from 8 to 12. The Primary part number is
defined as bits[15:4] by the "SSE-310 with M85 and U55 FPGA"
documentation. For example for the mps3-an547, 0x547 is 12 bits but we
only return 8 bits right now.
Signed-off-by: Simon Xu <simonxhy0404@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260724160943.52509-3-simonxhy0404@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Simon Xu [Fri, 24 Jul 2026 16:09:42 +0000 (11:09 -0500)]
hw/misc/mps2-scc.c: fix cfg7 write
Change the CFG7 write function to modify the correct variable. This only
affects the an536 machine currently as only it uses cfg7 to store the
core 1 vector table base address.
Signed-off-by: Simon Xu <simonxhy0404@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260724160943.52509-2-simonxhy0404@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Describe the current OpenBMC target naming and release status for
Nuvoton machines. The latest 2.18.0 release no longer includes GSJ,
so point users at older 2.14.0 sources and explain how to find
Jenkins MTD artifacts.
Signed-off-by: Bin Meng <bin.meng@processmission.com>
Message-id: 20260627063208.33642-1-bin.meng@processmission.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Bernhard Beschow [Mon, 27 Jul 2026 09:28:47 +0000 (10:28 +0100)]
hw/net/can/flexcan: Remove RX SMB raw view
Use the existing `rx_smb0` message buffer view for register masks instead
of the raw register array. Since all accesses now use the structured view,
remove the redundant `rx_smb0_raw` union member.
Signed-off-by: Bernhard Beschow <shentey@gmail.com> Tested-by: Pavel Pisa <pisa@fel.cvut.cz> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260723070059.6332-10-shentey@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Bernhard Beschow [Mon, 27 Jul 2026 09:28:47 +0000 (10:28 +0100)]
hw/net/can/flexcan: Fix RXIMR reset mask
The RXIMR registers are not affected by soft reset, so their reset mask
must preserve all entries. Set the mask for the entire array instead of
only the first register.
Signed-off-by: Bernhard Beschow <shentey@gmail.com> Tested-by: Pavel Pisa <pisa@fel.cvut.cz> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260723070059.6332-9-shentey@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Bernhard Beschow [Mon, 27 Jul 2026 09:28:46 +0000 (10:28 +0100)]
hw/net/flexcan: Drop oversized 'mb[]' mailbox view
As indicated in the comments, the `mb[]` a.k.a. `mbs []` views should
cover 0x400 (1024) bytes. However, the `mb[]` array covers four times
the size since `sizeof(FlexcanRegsMessageBuffer)` returns the size in
bytes instead of counting the number of uint32_t fields. This shifts the
subsequent register offsets by 0xc00 which is not intended. Fix the size
and thus the offsets by dropping the now unused `mb[]` view.
Note that the different size changes the migration layout. Since the device
model is new, no change in the version fields is needed.
Signed-off-by: Bernhard Beschow <shentey@gmail.com> Tested-by: Pavel Pisa <pisa@fel.cvut.cz> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260723070059.6332-8-shentey@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The mailbox reset mask initialized only the first word of the raw `mb[]`
array. Fix the initialization to cover the whole mailbox, as indicated
in the field description in the header. While at it, use the `mbs[]`
view instead in order to drop the redundant and oversized `mb[]` view in
the next commit.
Signed-off-by: Bernhard Beschow <shentey@gmail.com> Tested-by: Pavel Pisa <pisa@fel.cvut.cz> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260723070059.6332-7-shentey@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Bernhard Beschow [Mon, 27 Jul 2026 09:28:46 +0000 (10:28 +0100)]
hw/net/can/flexcan: Fix mailbox index calculation in flexcan_mem_read()
Calculate mailbox indices from the `mbs[]` array layout instead of the
oversized raw `mb[]` view. This prevents accessing mailbox entries beyond
the valid array range and fixes Coverity CID 1662974.
Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Bernhard Beschow <shentey@gmail.com> Tested-by: Pavel Pisa <pisa@fel.cvut.cz> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260723070059.6332-6-shentey@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Bernhard Beschow [Mon, 27 Jul 2026 09:28:46 +0000 (10:28 +0100)]
hw/net/can/flexcan: Fix mailbox index calculation in flexcan_mem_write()
Calculate mailbox indices from the `mbs[]` array layout instead of the
oversized raw `mb[]` view. This prevents accessing mailbox entries beyond
the valid array range and fixes Coverity CID 1662974.
Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Bernhard Beschow <shentey@gmail.com> Tested-by: Pavel Pisa <pisa@fel.cvut.cz> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260723070059.6332-5-shentey@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Bernhard Beschow [Mon, 27 Jul 2026 09:28:46 +0000 (10:28 +0100)]
hw/net/can/flexcan: Fix out-of-bounds access in flexcan_mx_rx()
Require `last_not_free_to_receive_mbid >= 0` before indexing `mbs[]`.
This prevents a possible `-1` array index and fixes Coverity CID 1662790.
Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Bernhard Beschow <shentey@gmail.com> Tested-by: Pavel Pisa <pisa@fel.cvut.cz> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260723070059.6332-4-shentey@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Bernhard Beschow [Mon, 27 Jul 2026 09:28:46 +0000 (10:28 +0100)]
hw/net/flexcan: Drop unused RX FIFO register overlay
Remove the unused `FlexcanRegsRXFifo` union view now that FIFO accesses
use the underlying `mbs[]` array directly.
Signed-off-by: Bernhard Beschow <shentey@gmail.com> Tested-by: Pavel Pisa <pisa@fel.cvut.cz> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260723070059.6332-3-shentey@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Bernhard Beschow [Mon, 27 Jul 2026 09:28:46 +0000 (10:28 +0100)]
hw/net/can/flexcan: Use mbs[] array for FIFO pop
Implement FIFO entry shifting using the underlying `mbs[]` array instead
of the overlapping `fifo` union view. This makes it explicit that the
operation copies within a contiguous mailbox array and avoids Coverity
CID 1662971.
Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Bernhard Beschow <shentey@gmail.com> Tested-by: Pavel Pisa <pisa@fel.cvut.cz> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-id: 20260723070059.6332-2-shentey@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Use the stub library introduced in commit 0da978cdbc6 ("target/arm:
define stub library") to prevent symbol conflicts.
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260721122135.6288-5-philmd@oss.qualcomm.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
hw/intc/arm_gicv3: Fix ARM_GICV3 dependency for KVM / WHPX
KVM and WHPX GICv3 implementations call gicv3_init_irqs_and_mmio()
which is defined in arm_gicv3_common.c, itself build when ARM_GIC
is selected. Both KVM and WHPX are conditional on ARM_GICV3,
itself selecting ARM_GIC. Only build the ARM_GICV3 accelerator
variants when ARM_GICV3 is selected.
On real SH4 hardware, the address space is split between user mode
(U0, 0x00000000-0x7fffffff) and kernel mode (P1-P4, 0x80000000-0xffffffff),
so TARGET_VIRT_ADDR_SPACE_BITS was set to 31 for CONFIG_USER_ONLY.
However, qemu-user does not emulate the MMU, so this limit is not needed.
The only effect is to restrict reserved_va to 2 GB, causing OOM failures
for memory-intensive builds (e.g. webkit2gtk on Debian sh4 buildds).
Set TARGET_VIRT_ADDR_SPACE_BITS to 32 unconditionally, like most other
32-bit targets. Also fix the TASK_UNMAPPED_BASE macro to use 1ull instead
of 1u to avoid undefined behavior when shifting by 32.
Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Helge Deller <deller@gmx.de> Signed-off-by: Helge Deller <deller@gmx.de>
tests/functional/ppc: skip remote interrupts test if -net user not built
While running remote interrupts test, without libslirp-devel installed,
facing the following panic logs.
File
...
raise VMLaunchFailure(
...<3 lines>...
) from exc
...
Output: qemu-system-ppc64: -netdev user,id=net0: network backend
'user' is not compiled into this binary
Adding netdev user requirement for this test.
Suggested-by: Amit Machhiwal <amachhiw@linux.ibm.com> Reviewed-by: Amit Machhiwal <amachhiw@linux.ibm.com> Suggested-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Fixes: 63f5ba80921 ("tests/functional: Add remote interrupts test for PowerNV") Signed-off-by: Shivang Upadhyay <shivangu@linux.ibm.com> Tested-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Message-ID: <20260728074612.42397-1-shivangu@linux.ibm.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Mark Cave-Ayland [Sat, 25 Jul 2026 12:33:22 +0000 (13:33 +0100)]
target/sparc: set reg window data structures currently after vmstate load
In the SPARC CPU state, env->regwptr points into the env->regbase
array at wherever the architectural CWP (current window pointer) says
we are in the register windows. We don't migrate this directly,
since it's a host pointer, so we must ensure it is set up again
after migration load.
We also have to deal with a special case when CWP is (nwindows - 1).
In this case, while running we keep the "in" register data for this
window in a temporary location at the end of the regbase[] array, so
that generated code doesn't have to special case this "wrap around"
case. In cpu_pre_save() we call cpu_set_cwp() to force a copy of the
wrapped data from its temporary location into the architectural
location in window 0's "out" registers. We then migrate only
(nwindows * 16) entries in the regbase[] array. So on the
destination we need to copy the "in" register data back to its
temporary location again.
For 32-bit SPARC we get this right, because the CWP is in the PSR.
The get_psr() function does:
env->cwp = 0;
cpu_put_psr_raw(env, val);
which causes cpu_put_psr_raw() to call cpu_set_cwp() in a way that
sets up both regwptr and the wrapped-register data.
However, for 64-bit SPARC the CWP is not in the PSR, and
cpu_put_psr_raw() will not call cpu_set_cwp(). This leaves the guest
register state in a corrupted state, and the guest will likely crash
on the destination if it didn't happen to be executing with CWP == 0.
Fix this by adding a custom vmstate_cwp VMStateInfo with corresponding
get_cwp() and put_cwp() helpers which does the same for the 64-bit
case.
Cc: qemu-stable@nongnu.org Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260725123411.993099-1-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
hw/net/igb: recalculate rx_desc_len on migration load
rx_desc_len is migrated as a raw uint8_t from the stream but is a
derived value. Currently igb_rx_use_legacy_descriptor() is a stub
that always returns false, so rx_desc_len is always set to
sizeof(union e1000_adv_rx_desc). Recalculate it in post_load to
prevent a crafted migration stream from setting an invalid value.
Cc: qemu-stable@nongnu.org Signed-off-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-ID: <20260722112449.1386162-3-lvivier@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
hw/net/e1000e: recalculate rx_desc_len on migration load
rx_desc_len is migrated as a raw uint8_t from the stream, but it
is a derived value that can be computed from the register state
in core.mac[RFCTL] and core.mac[RCTL]. A crafted migration stream
can set rx_desc_len to an invalid value (e.g. 64), causing a stack
buffer overflow in e1000e_write_packet_to_guest() which copies
rx_desc_len bytes into a 32-byte stack union.
Recalculate rx_desc_len and other derived values from the register
state in post_load, ignoring the untrusted values from the stream.
Bernhard Beschow [Mon, 20 Jul 2026 20:11:33 +0000 (22:11 +0200)]
hw/sd/sdhci: Extract uSDHC-specific quirk
In Linux, the ESDHC_MIX_CTRL quirk is guarded by esdhc_is_usdhc() while
the eSDHC code path uses the standard SDHC interface. Extract the quirk
into a new `usdhc_write()` function.
Fixes file system corruption on emulated i.MX53 where Linux'
esdhc_is_usdhc() returns false. The same likely happens on e500 and
imx25-pdk machines.
Cc: qemu-stable@nongnu.org Fixes: 75e98bc4f859 ("hw/sd/sdhci: Add TYPE_FSL_ESDHC_BE") Reviewed-by: Bin Meng <bin.meng@processmission.com> Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Message-ID: <20260720201133.24796-3-shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Matt Turner [Sun, 26 Jul 2026 00:55:27 +0000 (20:55 -0400)]
linux-user: fix guards for the fsmount(2) syscall series
The fsopen(), fsconfig(), fsmount() and fspick() implementations are
guarded by defined(NR_fsopen) rather than defined(__NR_fsopen). No such
macro exists, so the guard is never true and the entire series compiles
out. Guests calling any of the four get -ENOSYS, which for example makes
systemd's credential setup fail with EXIT_CREDENTIALS for most units.
The strace bits for fsconfig() have the same typo.
Check if FSCONFIG_SET_FLAG is defined to avoid build errors in the strace
code on some older distributions (Helge).
Fixes: 767c32fe6983 ("linux-user: implement fsmount(2) series of syscalls") Fixes: 6e0aa9f6c731 ("linux-user/strace: add fsmount series of syscalls") Signed-off-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Helge Deller <deller@gmx.de> Signed-off-by: Helge Deller <deller@gmx.de>
Peter Maydell [Mon, 6 Jul 2026 16:27:04 +0000 (17:27 +0100)]
hw/net/xilinx_axienet: Don't write checksums off end of packet
The xilinx_axienet device has ethernet checksum offloading, with a
mode where the guest provides the offsets within the packet where
the data to be checksummed starts, and where the final checksum
should be written into the packet.
We don't sanity check the TX_CSINSERT offset before writing the
checksum data into it, which means the guest can pass us a value that
is larger than the packet itself and cause us to write the checksum
off the end of the buffer. We also don't explicitly check the
TX_CSBEGIN offset; this doesn't currently cause any problems because
we will pass a negative length to net_checksum_add() which does
nothing, but it's a potential trap for the future if the type
used for the length gets changed to be unsigned.
Explicitly check the offsets. The datasheet doesn't say what happens
if the guest misprograms this, so we choose to log an error and send
the packet as-is.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3599 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260706162704.787495-1-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
* tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu: (30 commits)
virtio: avoid packed vring virtio_queue_empty() infinite loops (CVE-2026-16457)
backends/rng: cap request size to avoid oversized allocation
hw/virtio-rng: Fix host use-after-free (CVE-2026-50624)
hw/net/virtio-net: Protect from DMA re-entrancy bugs
intel_iommu: Check address mask before using it in pasid-based iotlb invalidation
hw/cxl: fix OOB access in cxl_doe_cdat_rsp via entry_handle
hw/virtio/vdpa-dev: pass set_config buffer to vhost backend
hw/pci-host/q35.c: Avoid early return in mch_write_config()
hw/pci-host/q35.c: Factor out creation of SMRAM MRs
hw/pci-host/q35.c: Always initialize smram-region even if SMM disabled
virtio-snd: check for overflow before g_malloc0
virtio-snd: check rx buffer descriptor size
virtio-iommu: fix OOM due to unbounded call_rcu
libvduse: validate vq size
libvhost-user: fix heap overflow in vu_check_queue_inflights
libvhost-user: validate last_batch_head in vu_check_queue_inflights
virtio-pmem: wait for flush requests on unrealize
vhost-user: assert nregions within limit
virtio: fail early on bad config_len in migration
virtio: stop migrating num_default, validate vring.num on load
...
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Mon, 27 Jul 2026 20:51:16 +0000 (16:51 -0400)]
Merge tag 'pull-request-2026-07-27' of https://gitlab.com/thuth/qemu into staging
* Validate bounds in CXL "Set Feature" payloads
* Fix guest-triggerable heap OOB access in "usb-uas" device
* Fix possible crash via NULL pointer in ide_cancel_dma_sync()
* Avoid possible assert() usb_packet_copy()
* Check return value of xhci_xfer_create_sgl() for errors
* tag 'pull-request-2026-07-27' of https://gitlab.com/thuth/qemu:
hw/usb/hcd-xhci: Check return value of xhci_xfer_create_sgl() for errors
hw/usb/core: Avoid possible assert() in do_parameter() --> usb_packet_copy()
hw/ide/core: Fix possible crash via NULL pointer in ide_cancel_dma_sync()
hw/usb/dev-uas: Fix guest-triggerable heap OOB access
hw/cxl: Validate Set Feature payload bounds
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Virtqueue handler functions in device emulation code often look
something like this:
while (!virtio_queue_empty(vq)) {
...pop and process virtqueue element...
}
virtio-blk, virtio-scsi, virtio-crypto, and vhost-shadow-virtqueue use
this pattern.
The device may break (i.e. hit an error that requires device reset)
during the loop. virtio_queue_empty() returns 1 for broken split vrings
but not for broken packed vrings, leading to an infinite loop.
Adjust the packed vring behavior to match split vrings and avoid
infinite loops.
Fixes: CVE-2026-16457
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3968 Reported-by: Anatol Belski <anbelski@linux.microsoft.com> Signed-off-by: Stefan Hajnoczi <stefanha@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: <20260721134424.196337-1-stefanha@redhat.com>
projects / thirdparty / qemu.git / log
