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
Peter Maydell [Mon, 20 Jul 2026 18:05:29 +0000 (19:05 +0100)]
target/arm: GICv5 cpuif: gicr_cdia_read() ppibit should be 64 bits
In gicr_cdia_read() we turn a PPI interrupt ID into a register
index and a bit mask with a 1 for the bit we want to change:
ppireg = id / 64;
ppibit = 1ULL << (id % 64);
However, we used the wrong type for ppibit, making it a uint32_t. If
'id' is too large we'll shift off the end, so we won't ever update
the state of PPIs with indexes above 31.
This didn't have any visible effects because the currently allocated
architected PPIs are indexes 0..31, so you'd only see this if for
some reason a guest was manually marking as pending a PPI in 32..63.
Fix the type of ppibit to the intended 64 bit width.
Fixes: 3f79212abae89 ("target/arm: GICv5 cpuif: Implement GICR CDIA command") 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-2-peter.maydell@linaro.org
Jay Chang [Mon, 20 Jul 2026 18:05:29 +0000 (19:05 +0100)]
hw/net/xilinx_axienet: Fix PHY register 17 link status reporting
The Marvell 88E1111 PHY register 17 (PHY Specific Status Register)
bit 10 reports real-time link status. Previously, this register
returned a fixed value of 0x8800 with bit 10 always cleared,
causing U-Boot to always detect "No link" even when the link
was up.
Signed-off-by: Jay Chang <jay.chang@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com>
Message-id: 20260713064617.85374-1-jay.chang@sifive.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Tao Ding [Mon, 20 Jul 2026 18:05:29 +0000 (19:05 +0100)]
hw/char: imx_serial: add missing migration state
The imx_serial vmstate is missing the ucr2 field. This register
includes important state like the transmit enable and receive enable
bits, so it's likely that after a migration the UART will be in a
completely broken state. This bug has been present ever since
the UART code was first added to QEMU.
Add ucr2 from imx_serial to vmstate, and increment the version_id.
This is a migration compatibility break, but this UART is only used
in the various imx-based boards, where we are OK with compat breaks.
Migrating on sabrelite can reproduce this issue:
1. Prepare the U-Boot required for sabrelite. (according to sabrelite.rst)
2. Compile qemu
$ mkdir build && cd build && ../configure --target-list="arm-softmmu" && make -j4
3. Start sabrelite and prepare for migration
$ ./build/qemu-system-arm -M sabrelite \
-smp 1 -m 1G -display none -serial null -serial mon:stdio \
-kernel ~/u-boot
4. Enter qemu monitor after uboot. (ctrl + a + c)
(qemu) stop
(qemu) xp /4wx 0x021e8084 021e8084: 0x00004027 0x00000784 0x00008000 0x00000a01
(qemu) migrate -d file:vmstate
(qemu) q
(ctrl + a + c)
QEMU 11.0.50 monitor - type 'help' for more information
(qemu) xp /4wx 0x021e8084 021e8084: 0x00000004 0x00000784 0x00008000 0x00000a01
(qemu) q
It can be found that the data for address 0x021e8084 (register of usr2 in imx_serial of sabrelite)
is not the data before the migration.
After being repaired:
$ ./build/qemu-system-arm -M sabrelite \
-smp 1 -m 1G -display none -serial null -serial mon:stdio \
-kernel ~/u-boot -incoming file:vmstate
(ctrl + a + c)
QEMU 11.0.50 monitor - type 'help' for more information
(qemu) xp /4wx 0x021e8084 021e8084: 0x00004027 0x00000784 0x00008000 0x00000a01
Cc: qemu-stable@nongnu.org Fixes: 40b6f91151 ("i.MX: UART support") Signed-off-by: Tao Ding <dingtao0430@163.com>
Message-id: 20260715131819.14827-2-dingtao0430@163.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Stefan Hajnoczi [Thu, 11 Jun 2026 12:54:38 +0000 (08:54 -0400)]
iotests/108: avoid leaking FUSE mount
The QEMU s390x CI gitlab-runner recently broke because qemu-iotests 108
FUSE mount leaked and prevented the setup of the gitlab-runner
environment:
chmod: cannot access '/home/gitlab-runner/builds/P3MFS4LUf/0/qemu-project/qemu/build/scratch/qcow2-file-108/fuse-export': Transport endpoint is not connected
Always umount the FUSE export when cleaning up to prevent the leak.
Closes: https://gitlab.com/qemu-project/qemu/-/work_items/3541 Cc: Hanna Czenczek <hreitz@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20260611125438.194479-1-stefanha@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* tag 'next-pull-request' of https://gitlab.com/peterx/qemu:
migration: clean up postcopy blocktime presentation
migration: fix ineffective overflow assert in postcopy blocktime
migration: Fix invalid %ud format and trace arg typo
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* tag 'pull-request-2026-07-20' of https://gitlab.com/thuth/qemu:
hw/usb/hcd-xhci-sysbus: Fix OOB heap access in xhci_sysbus_intr_raise()
hw/usb/hcd-xhci: Fix guest-triggerable assert() in xhci_find_stream()
usbredir: fix infinite loop and SIGFPE with zero max_packet_size
usbredir: fix use-after-free on buffered bulk packet overflow
tests/qtest: add xhci-pci unplug finalize regression test
hw/usb/hcd-xhci-pci: break host link cycle so device_finalize() runs on unplug
hw/usb/xhci: clamp interval exponent to avoid UB shift in xhci_init_epctx()
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Thomas Huth [Sun, 19 Jul 2026 06:15:28 +0000 (08:15 +0200)]
hw/usb/hcd-xhci-sysbus: Fix OOB heap access in xhci_sysbus_intr_raise()
Some machines like the microvm machine instantiate a "sysbus-xhci"
device with just 1 interrupt (by setting the "intrs" property to 1).
xhci_sysbus_realize() then only allocates the s->irq array with one
entry.
When the guest writes to the ERDP register of a corresponding XHCI
"interrupter", the generic XHCI code calls the xhci_sysbus_intr_raise()
function with n > 1, and this function then calls qemu_set_irq() with
s->irq[n] pointing to a bad heap address. The qemu_set_irq() then tries
to call an IRQ handler via a function pointer in that heap space. This
either causes QEMU to die with a segmentation fault (if it's a bad
address), or even worse runs some unexpected code if the destination
of the pointer is executable code.
Looking at the xHCI spec, it is up to the implementation of the host
controller how many interrupters are available. So if we only support
one or some few interrupters, the registers of the other interrupters
should not do anything, i.e. reads should result in zeros and writes
should be completely ignored. (big thanks to Peter Maydell for helping
with the analyzation of the correct way to fix this here)
This way, the xhci_sysbus_intr_raise() function cannot be called with
an invalid interrupt number anymore. But for good measure, also add an
assert() statement to the xhci_sysbus_intr_raise() function to prevent
that similar problems with calling arbitrary function pointers on the
heap could occur again.
Fixes: CVE-2026-16043
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4001 Reported-by: Tristan Madani <tristan@talencesecurity.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260719061528.15587-1-thuth@redhat.com>
Thomas Huth [Wed, 15 Jul 2026 20:33:57 +0000 (22:33 +0200)]
hw/usb/hcd-xhci: Fix guest-triggerable assert() in xhci_find_stream()
The assert() statement in xhci_find_stream() can be triggered by
the guest (see bug tickets #273, #3895 and #3988 on gitlab.com).
Turn it into a qemu_log_mask() instead to fix this problem.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/273 Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260715203357.424556-1-thuth@redhat.com>
usbredir: fix infinite loop and SIGFPE with zero max_packet_size
A malicious usbredir peer can send an ep_info message resetting
max_packet_size to 0 after bulk receiving has started. This causes:
- infinite loop in usbredir_buffered_bulk_packet() where the splitting
loop increments by max_packet_size (0)
- SIGFPE in usbredir_buffered_bulk_in_complete_ftdi() from modulo by 0
- SIGFPE in usbredir_handle_buffered_bulk_in_data() from division by 0
when computing bytes_per_transfer
Fix by stopping and disabling bulk receiving in usbredir_ep_info() when
max_packet_size is set to 0.
Add post-load check, and assert() for the invariant.
usbredir: fix use-after-free on buffered bulk packet overflow
When usbredir_buffered_bulk_packet() splits a multi-fragment buffered
bulk packet into max-packet-size chunks, only the final fragment owns
the shared parser allocation (via free_on_destroy). If bufp_alloc()
drops the final fragment due to queue overflow, it frees the backing
buffer while earlier fragments already queued still hold interior
pointers into it. Subsequent guest bulk-IN transfers then read from
freed heap memory.
Fix this by tracking how many fragments were queued during the current
packet. When bufp_alloc() fails, remove all already-queued fragments
from the tail of the endpoint queue before breaking out of the loop.
If the dropped fragment was non-final, free the data buffer explicitly
since no fragment took ownership.
Fixes: CVE-2026-15705 Fixes: b2d1fe67d09d ("usbredir: Add support for buffered bulk input (v2)")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3808 Reported-by: Feifan Qian <bea1e@proton.me> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260714185717.1156157-1-marcandre.lureau@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Xiangfeng Cai [Thu, 18 Jun 2026 11:01:19 +0000 (19:01 +0800)]
tests/qtest: add xhci-pci unplug finalize regression test
Add a qtest that hot-adds an nec-usb-xhci controller, requests unplug,
resets the system to process the request, and waits for DEVICE_DELETED.
This covers the xHCI PCI host-link refcount cycle by verifying that
device_finalize() runs after unplug.
Signed-off-by: Xiangfeng Cai <caixiangfeng@bytedance.com>
Message-ID: <20260618110119.3084296-3-caixiangfeng@bytedance.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Xiangfeng Cai [Thu, 18 Jun 2026 11:01:18 +0000 (19:01 +0800)]
hw/usb/hcd-xhci-pci: break host link cycle so device_finalize() runs on unplug
The xHCI PCI wrapper embeds an xhci-core child via object_initialize_child()
and, in usb_xhci_pci_realize(), points the child's "host" link back at the PCI
device:
"host" is a DEFINE_PROP_LINK property, which qdev registers as an
OBJ_PROP_LINK_STRONG link. A strong link takes a reference on its target, so
this creates a refcount cycle: the PCI device owns the child, and the child's
strong link pins the PCI device.
On unplug (guest ACPI eject or QMP device_del), pci_qdev_unrealize() calls
pc->exit() but never unrealizes the no-bus child. object_unparent() then drops
only the parent/bus references, leaving the link reference in place. The PCI
device stays at refcount 1 forever, so object_finalize()/device_finalize() is
never reached. Symptom observed under gdb after eject:
p *((Object *)dev) => ref = 1, parent = 0x0, realized = false
p ((XHCIPciState *)dev)->xhci.hostOpaque => points back at dev
Fix usb_xhci_pci_exit() to tear down the embedded child explicitly: unrealize
it first (so the set-link-before-realize check passes), then clear the "host"
link. This releases the strong reference, lets the PCI device refcount reach 0,
and allows device_finalize() to run.
Fixes: 8ddab8dd3d81 ("usb/hcd-xhci: Split pci wrapper for xhci base model") Signed-off-by: Xiangfeng Cai <caixiangfeng@bytedance.com> Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260618110119.3084296-2-caixiangfeng@bytedance.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
hw/usb/xhci: clamp interval exponent to avoid UB shift in xhci_init_epctx()
The xHCI endpoint context dword 0 bits 23:16 ("Interval") are written
by the guest and passed directly as the shift amount in:
epctx->interval = 1 << ((ctx[0] >> 16) & 0xff);
The shift amount can be 0-255. Shifting a 32-bit `int` left by >= 32
is undefined behaviour under C11 §6.5.7p4. With UBSan
(halt_on_error=1) this causes QEMU to abort; with aggressive compiler
optimisations that assume UB is unreachable the result is
unpredictable.
Clamp the exponent to [0, 18] with MIN() before the shift, and use
`1u` (unsigned) to avoid shifting a signed integer. The xHCI
specification defines a maximum meaningful Interval value of 18 for
most endpoint types; thus clamping to 18 is a safe fix that
preserves the full unsigned 32-bit range for any compliant value.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3703 Reported-by: Feifan Qian <bea1e@proton.me> Signed-off-by: Feifan Qian <bea1e@proton.me>
[thuth: Clamp to 18 instead of 31] Signed-off-by: Thomas Huth <thuth@redhat.com>
Stefan Hajnoczi [Sat, 18 Jul 2026 23:17:14 +0000 (19:17 -0400)]
Merge tag 'hex-next-express-pull-request' of https://github.com/qualcomm/qemu into staging
Hexagon fix queue
Fixes for these issues:
* fix unaligned scalar accesses (now correctly faults/raises exception)
* fix build error with --disable-hexagon-idef-parser and gcc 14
* fix system emulation bugs: packet sreg writes, PC stuck on non-COF TB-end
* fix debug accesses w/MMU
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEPWaq5HRZSCTIjOD4GlSvuOVkbDIFAmpafbcACgkQGlSvuOVk
# bDIdcRAAn5KmbHrrVpx7IArEybXMOnnARkacIUOmMWIY9zcU7e3jcq3BvdYysG3r
# VmcsUa/r0jxV8ix0TZui6qTtikNOmS2GPf4q4TxopwCv+YCteKPK5cLXmZ3cmMPM
# nv3Maoe3WnIVY9ZMTSIA3B+BY2QlfCSKb71Q4Ll8KkI19sX0t4lkQbjeMLkAkOML
# Kg5u7+A4uGVD9WFWxjn0G3Uuji5+xOqvPPTiM1oi8IIT/jUDREx1M4yQU0s/o3y1
# 0wVhCAwkbqCrSi1Kkwk23WSFDtA5l9ggFN52lNoJkwgDbVXZ6MZnTanbgR58mlGB
# 09CzAA4QbNMpL9chbQiY4T9utni3td7RC+edCAd+r5+pBIzQn25dLVUAutqqVOiH
# g90x/HBx9sv8MiFcYRCsSZ4bhcnfW2Wip58Ub/7lkMb90/2OOhcORpeufMHqkNfj
# IsMLRoMPXdT/YLyCsALK7WW8zYpFyFlFPcX475T9Z/D1Pr/UN2SGoNe4L9hltCdI
# 0E/5NcDHBuKYxua+v4wKzPxAYsBBcS0ldfCjwiuef3CR6V7xQVYRvjvOHtckl5+B
# k3fXyORqtkF00B4cuGNIXPFV5z+ei4WTPKBZlxn4/rmDf4sdZcoHowEFMp1hbI2L
# 8yPTswzKHByIibFg8wF6xzE/duoS2Lo+eg9WBfvr3UY8WQtz44w=
# =Q8R/
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 17 Jul 2026 15:08:39 EDT
# gpg: using RSA key 3D66AAE474594824C88CE0F81A54AFB8E5646C32
# gpg: Good signature from "Brian Cain (OSS Qualcomm) <brian.cain@oss.qualcomm.com>" [unknown]
# gpg: aka "Brian Cain <bcain@kernel.org>" [unknown]
# gpg: aka "Brian Cain (QuIC) <bcain@quicinc.com>" [unknown]
# gpg: aka "Brian Cain (CAF) <bcain@codeaurora.org>" [unknown]
# gpg: aka "bcain" [unknown]
# gpg: aka "Brian Cain (QUIC) <quic_bcain@quicinc.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: 6350 20F9 67A7 7164 79EF 49E0 175C 464E 541B 6D47
# Subkey fingerprint: 3D66 AAE4 7459 4824 C88C E0F8 1A54 AFB8 E564 6C32
* tag 'hex-next-express-pull-request' of https://github.com/qualcomm/qemu:
tests/functional/hexagon: add arch_tests functional test
target/hexagon: fix PC not advancing for non-COF TB-ending packets
target/hexagon: initialize deferred sreg-write temps to current value
target/hexagon: fix get_phys_addr_debug with in-page offset
tests/tcg/hexagon: add unaligned scalar test
target/hexagon: raise SIGBUS on unaligned data access in sysemu
target/hexagon: raise SIGBUS on unaligned scalar stores
target/hexagon: raise SIGBUS on unaligned scalar loads
target/hexagon: handle misaligned load/store cause codes in cpu_loop
target/hexagon: fix -Wshadow=local build error on GCC 14
gitlab-ci: build hexagon-softmmu to enable functional test
tests/docker: hexagon fix podman untar, 22.1.8
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Peter Maydell [Mon, 13 Jul 2026 14:14:29 +0000 (15:14 +0100)]
linux-user/sparc: Take pending signals in sparc64_set_context()
Every callsite of block_signals() checks its return value, except
the one in sparc64_set_context(). Generally you need to check,
because the standard pattern is:
if (block_signals()) {
return -QEMU_ERESTARTSYS;
}
/* do some blocking syscall */
and we need to take any pending signal before we do the blocking
operation, not afterwards.
The use in sparc64_set_context() doesn't do this. It doesn't have to
because the operations it is doing aren't blocking, so it won't get
into "we didn't take the signal that we should have" races that
blocking syscalls do. But it does make this way of updating the
signal mask inconsistent with how we do it in do_sigprocmask().
do_sigprocmask() does the usual "return -QEMU_ERESTARTSYS", so a
pending signal that was not blocked by the old signal mask and which
will be blocked by the new mask we're about to install will be taken
before we change the mask. sparc64_set_context() doesn't check the
return value, so we won't take that pending signal. That's not
wrong, because it just means the signal lost the race with the
executing code. But it seems clearer to behave the same way as
do_sigprocmask(), not differently.
Make sparc64_set_context() check the return value of block_signals()
and return early if there's a pending signal to take. We don't need
to return a separate return code to indicate this because the main
loop handles it the same either way.
Fixes: e0f0ce88eb9 ("linux-user/sparc: call block_signals() before set_sigmask() in setcontext") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
Stefan Hajnoczi [Sat, 18 Jul 2026 21:32:11 +0000 (17:32 -0400)]
Merge tag 'pbouvier/pr/plugins-20260716' of https://gitlab.com/p-b-o/qemu into staging
Changes:
- [PATCH v2 0/2] plugins/execlog: fix segfault and flush output on vcpu (Harry van Haaren <harry.vanhaaren@openchip.com>) Link: https://lore.kernel.org/qemu-devel/20260716094126.787556-1-harry.vanhaaren@openchip.com
# -----BEGIN PGP SIGNATURE-----
#
# iQGzBAABCgAdFiEEN8FWlNi6l2Sxlz/btEQ30ZwoYt8FAmpZN5UACgkQtEQ30Zwo
# Yt/eGQv+OFExxMNfE2ZNGCEmXu9JQkZu7m+aXVVz0Vfq2PjV2Gyz5xuvllFeXpoq
# vgdJl/pUzqY457p8dqnKgOa/wB++J6u4692O5jYsUCYWIAweLZxFyRu5fl+r7yz4
# Yo0rkWvBFUZKVl5LpKKbaQnLqkmP17xTCeLk7PLu5Gh5hWfVK+ReBKogDOSp232K
# 8tvyB7JL9H5RoL9BurYXmyplFqjAOjRelYKFJ5bF4O7Ayo8vtCRVyIyk7ydKT43q
# 1w4BIRBFVaKwQ9VZVk01eXU11EP98hmwi9/umPpDdGkqZGL9qfqBTsdeQ3Ej/ifw
# ruwY3G2LDPQJCXlHOUE4RUoxw+naThyN/Y4dSyhtjSdimrpjAyB1sKCUxoVBKh84
# wBCzx99sh1g2RmtXzYa9c6cavGNnkuorSgmhL+0aKWL8T8oBbDW0m2vZCZJ/Vy41
# XkeR/HRq6ag29YB7pKLUpurou9a7vx4U4EgPf0/R9XqUkPqRws6Ma7jpxl/71GAt
# akiO6qgr
# =yj8L
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 16 Jul 2026 15:57:09 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-20260716' of https://gitlab.com/p-b-o/qemu:
plugins/execlog: fix execlog vcpu_exit execution print loss
plugins/execlog: fix segfault/race-cond on per-vCPU structures
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Brian Cain [Thu, 16 Jul 2026 19:15:54 +0000 (12:15 -0700)]
target/hexagon: fix PC not advancing for non-COF TB-ending packets
Add hex_next_PC, a global mirroring CPUHexagonState::next_PC,
and ctx->need_next_pc, so that gen_write_new_pc_addr() can write the
branch target through hex_next_PC instead of hex_gpr[HEX_REG_PC]
when a later unconditional write of PC is expected. gen_end_tb()
then commits hex_next_PC into hex_gpr[HEX_REG_PC] at the end of the
packet.
Previously, non-COF instructions that still end a TB did not advance the
PC, since next_PC's value was never written back into the PC register.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
Brian Cain [Thu, 16 Jul 2026 19:15:53 +0000 (12:15 -0700)]
target/hexagon: initialize deferred sreg-write temps to current value
Unconditionally allocate and initialize the temp to the sreg's current
value for every logged sreg write, rather than only allocating
when need_commit is set or the register is SSR.
Without this, reading a deferred sreg write within the same packet
before it is committed can observe an uninitialized temp instead
of the register's pre-packet value.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
target/hexagon: fix get_phys_addr_debug with in-page offset
As documented:
* @get_phys_addr_debug: Callback for obtaining a physical address.
* This must be able to handle a non-page-aligned address, and will
* return the physical address corresponding to that address.
When MMU is enabled, hexagon_cpu_get_phys_addr_debug() returns the
physical address page-aligned, not corrected to reflect the exact byte
the virtual addr maps to within the page. Let's fix that. The
MMU-disabled case is already correct.
This would break semihosting argument reads when it is added for Hexagon.
Signed-off-by: Matheus Tavares Bernardino <matheus.bernardino@oss.qualcomm.com> Reviewed-by: Brian Cain <brian.cain@oss.qualcomm.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
Brian Cain [Tue, 14 Jul 2026 01:09:54 +0000 (18:09 -0700)]
target/hexagon: raise SIGBUS on unaligned data access in sysemu
hexagon-softmmu had no enforcement of alignment for scalar loads and
stores: the MO_ALIGN flag added by the previous two commits triggers
TLB_INVALID_MASK/alignment faults in cputlb.c, but Hexagon's
TCGCPUOps did not implement do_unaligned_access, so the fault was
never delivered to the guest.
Add hexagon_cpu_do_unaligned_access(), which raises
HEX_CAUSE_MISALIGNED_LOAD/_STORE via the existing HEX_EVENT_PRECISE
path, mirroring raise_tlbmiss_exception()/raise_perm_exception().
Brian Cain [Tue, 14 Jul 2026 01:09:51 +0000 (18:09 -0700)]
target/hexagon: handle misaligned load/store cause codes in cpu_loop
Add a linux-user cpu_loop handler for HEX_CAUSE_MISALIGNED_LOAD and
HEX_CAUSE_MISALIGNED_STORE, raising SIGBUS for consistency with
hexswi.c's sysemu handling, even though linux-user's own alignment
check in accel/tcg/user-exec.c currently raises SIGBUS before
Hexagon's cause-code machinery is reached.
Brian Cain [Sat, 11 Jul 2026 18:54:33 +0000 (11:54 -0700)]
tests/docker: hexagon fix podman untar, 22.1.8
The debian-hexagon-cross image previously unpacked the codelinaro
clang+llvm hexagon toolchain by piping a .tar.zst archive straight
into "tar --zstd -xC". GNU tar restores the archive's stored file
modes on extraction, including lchmod() on symlinks. Under rootless
podman, where the build runs in a user namespace on overlay storage,
those chmod()/lchmod() calls are rejected with EPERM:
tar: .../libclang_rt.builtins.a: Cannot change mode to rwxrwxrwx: \
Operation not permitted
tar: .../x86_64-linux-gnu: Cannot change mode to rwxr-xr-x: \
Operation not permitted
tar: Exiting with failure status due to previous errors
tar then exits non-zero and aborts the build, so debian-hexagon-cross
only builds reliably under docker, not rootless podman.
So instead we can switch to a different packaging. clang, lld
come from LLVM Debian builds from apt.llvm.org, instead of custom ones for
hexagon. And only the hexagon linux sysroot is required, avoiding the
tar issues.
Bin Guo [Thu, 16 Jul 2026 10:19:52 +0000 (18:19 +0800)]
migration: clean up postcopy blocktime presentation
Small cleanups for the postcopy blocktime fine-grained tracking
feature:
* Remove a redundant memset() on latency_buckets after g_new0().
* Use singular "Latency" in the HMP label for postcopy non-vCPU
latency, consistent with other single-value labels.
Bin Guo [Thu, 16 Jul 2026 10:19:50 +0000 (18:19 +0800)]
migration: fix ineffective overflow assert in postcopy blocktime
vcpu_faults_current[] is uint8_t. The overflow assert was checked
after the post-increment, so 255 would wrap to 0 and the assert
would pass silently. Move the check before the increment and use
< 255.
pixman_image_create_bits() returns NULL for allocation failures and
unaligned strides, which may be supplied by the guest with
VIRTIO_GPU_CMD_SET_SCANOUT_BLOB, and virtio_gpu_do_set_scanout()
subsequently dereferences it.
projects / thirdparty / qemu.git / log
