envlist_unsetenv() looked up the entry to remove with
strncmp(entry->ev_var, env, strlen(env)). The comparison length is
the requested name's length, so any stored entry whose name *starts*
with that name compares equal. envlist_setenv() inserts at the head
of the list, so the first hit wins: with FOO=... stored first and
FOOBAR=... stored afterward, envlist_unsetenv("FOO") iterates from
the head, matches FOOBAR=... on the prefix, and drops it instead of
FOO=...
linux-user and bsd-user reach this code via the -U command-line
switch, so the bug is reachable from a normal qemu-user invocation.
envlist_setenv() used the same strncmp pattern but with
envname_len = (eq_sign - env + 1), so the '=' byte sat inside the
compared window and acted as an implicit boundary. setenv was
therefore not buggy -- but the safety lived in the byte layout of
ev_var rather than in the entry, so a future edit could easily
drift the two sites apart again.
Store the name length on each entry at insertion time and compare
with explicit length equality plus memcmp via a small helper. Use
the helper at both lookup sites so the boundary becomes a
structural property of the entry: envlist_unsetenv() stops
prefix-matching, and envlist_setenv()'s self-search no longer
depends on the '=' byte serving as a sentinel.
Fixes: 04a6dfebb6 ("linux-user: Add generic env variable handling")
Signed-off-by: Denis V. Lunev <den@openvz.org>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20260520212628.479772-2-den@openvz.org
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Merge tpm 2026/06/01 v1
# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCgAdFiEEuBi5yt+QicLVzsZrda1lgCoLQhEFAmod/1EACgkQda1lgCoL
# QhGFmwf/SDA8DQGekVksB+TiDV11a+2I8FzBHJmQ2RhKbSGxY77ZbWei+Z45fU9/
# 2e0aDizw7GDRPGthKChjOYA5SAVf7gwUaSkhv21xDNgsddcdCr05y1RljOfShtbw
# S55XOk6Tx2zX/00nTqskyw9bqz2YwnAh5vPjfDWy6TV5k7Q3BlMyooFeJu/19pU7
# RnMLfHdJHlYSQ2Bn4ZT6agXsoQIvnJK51Poq0TJQo0PW8kWFwcp13Ic+uyvRfkF3
# U6JdTGBXJxCHMgIkO4EG4o5PT7Dy8miKFepJCUgyjHesi7iFYQlIAnsJth9anMjL
# zoqnMVNN1jVrcuzVLG9oNHB7+hZ/Eg==
# =Wlez
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 01 Jun 2026 17:53:21 EDT
# gpg: using RSA key B818B9CADF9089C2D5CEC66B75AD65802A0B4211
# gpg: Good signature from "Stefan Berger <stefanb@linux.vnet.ibm.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: B818 B9CA DF90 89C2 D5CE C66B 75AD 6580 2A0B 4211
* tag 'pull-tpm-2026-06-01-1' of https://github.com/stefanberger/qemu-tpm:
tpm_emulator: Disconnect if response exceeds negotiated buffer size
tpm_emulator: Reject a buffer size different than what was requested
hw/tpm: Add support for VM migration with TPM CRB chunking
test/qtest: Add test for tpm crb chunking
hw/tpm: Implement TPM CRB chunking logic
hw/tpm: Add internal buffer state for chunking
hw/tpm: Refactor CRB_CTRL_START register access
hw/tpm: Add TPM CRB chunking fields
ui/vdagent: Use VMSTATE_GBYTEARRAY to safely migrate outbuf
migration/vmstate: Add VMState support for GByteArray
tests: Add a TPM TIS I2C swtpm test
tests: Check whether the I2C master flag is set
tests: Rename id of tpmdev to tpm0
tests: Convert string arrays to byte arrays
tests: Have TPM I2C read/write functions take QTestState as first parameter
tests: Move TPM I2C bus read/write functions to common files
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
testing updates:
- revert test/Makefile.include move due to regression
- work-around move with explicit targets for MacOS gitlab
- use debian-all-test-cross for MIPS TCG tests
# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmodsKwACgkQ+9DbCVqe
# KkQ8jQf/Xydd5C6H5WOjLMk0i+fbiiFeZUVZ0uIwWrWEjDNGVdbT575/bS39PKeh
# 2UTANzcePKP3VLsWYw8E/8fWSkdUFi47lGRZHjQN6cbPo7cC3NskkOTkumvE9Fr9
# NuGmbw2FVFnmn6xkZCYSHdj2MQeGf9dy9hyGlivTfsmj8ypw92uMzp1/vvfC5wH1
# la1RIPDRUngQmHK+PUQQTVdWgpWETier7QGqCyBWbk6Gc26O8L9xeiwR8Dhi+dPv
# 1cY8BvAWC+nOvDtCClahmEpTfiWALKtE8c+/EqP3QLCWDdAcUg7XGtTlX3iYIy+u
# 8nCt/HOpKynpuuxHrIoUs9q8FE9OuA==
# =SUZJ
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 01 Jun 2026 12:17:48 EDT
# gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44
# gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.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: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44
* tag 'pull-11.1-testing-hotfix-010626-1' of https://gitlab.com/stsquad/qemu:
configure: use debian-all-test-cross for mipsel tcg tests
gitlab: work around the inability to build targets for MacOS
Revert "Makefile: include tests/Makefile.include before ninja calculation"
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
When the TIS, SPAPR, or CRB frontends negotiate a buffer size with the
TPM backend, then the tpm_emulator (swtpm) could still adjust this size
of the buffer to within bounds supported by swtpm+libtpms if the chosen
size was outside the acceptable range. This could theoretically lead to
the TPM 2 using a bigger buffer than what was requested and memory
allocated for. In practice this would not happend since the requested size
of 4096 bytes for TIS and SPAPR and 3968 bytes for CRB happen in the
(currently) supported range of ~2.5kb to 4096 bytes. With PQC support
the range will have an upper bound of 8kb and a lower bound that will
support the (pre-PQC) CRB with 3968 bytes.
Fixes: 9375c44fdf ("tpm: tpm_emulator: get and set buffer size of device")
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260511142219.797048-2-stefanb@linux.ibm.com
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
- Add subsection in VMState for TPM CRB with the newly introduced
command and response buffer GByteArrays, along with a needed callback,
so that newer QEMU only sends the buffers if it is necessary.
- Implement a migration blocker to prevent migration of the VM if the
user manually enables chunking capability, cap-chunk, but the machine
type does not support it, using a new hw_compat property called
allow_chunk_migration.
- Add a post_load_errp hook so that during a migration, the buffers are
validated before destination VM is started.
Signed-off-by: Arun Menon <armenon@redhat.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260506075813.120781-7-armenon@redhat.com
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
- New test case added to the swtpm test. Data is written and read from
the buffer in chunks.
- The chunk size is dynamically calculated by reading the
CRB_CTRL_CMD_SIZE address. This can be changed manually to test.
- Add a helper function tpm_wait_till_bit_clear()
- Note that this commit does not yet exercise the chunked read/write
logic, as current transfer sizes remain small. Testing for large
transfers is introduced in a subsequent patch: 'tests: Use ML-DSA-87
operations to cause large TPM transfers with CRB'
Signed-off-by: Arun Menon <armenon@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260506075813.120781-6-armenon@redhat.com
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
In GLib, GByteArray is an object managed by the library. Currently,
migrating a GByteArray requires treating it as a raw C struct and using
VMSTATE_VBUFFER_ALLOC_UINT32. For example, see vmstate_vdba in
ui/vdagent.c
QEMU cannot pretend that GByteArray is a C struct and simply use
VMS_ALLOC to g_malloc() the buffer. This is because, VMS_ALLOC blindly
overwrites the data pointer with a newly allocated buffer, thereby
leaking the previous memory. Besides, GLib tracks the array's capacity
in a hidden alloc field. Bypassing GLib APIs leave this capacity out of
sync with the newly allocated buffer, potentially leading to heap buffer
overflows during subsequent g_byte_array_append() calls.
This commit introduces VMSTATE_GBYTEARRAY which uses specific library
API calls (g_byte_array_set_size()) to safely resize and populate the
buffer.
Signed-off-by: Arun Menon <armenon@redhat.com>
Suggested-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260423105733.113046-2-armenon@redhat.com
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Unfortunately a previous fix to ensure .ninja-goals was set for the
TCG tests broken the ability to run check-functional-FOO. As we have
now reverted we need a solution for the MacOS gitlab run. The simplest
is to add an explicit make invocation to build the signed binaries
before we run the tests.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Tested-by: Cornelia Huck <cohuck@redhat.com> # running tests on an s390x
Message-ID: <20260601143129.144786-3-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
pull-loongarch-20260601
# -----BEGIN PGP SIGNATURE-----
#
# iLMEAAEKAB0WIQTKRzxE1qCcGJoZP81FK5aFKyaCFgUCah0tmwAKCRBFK5aFKyaC
# Fht2BACdtjM7Kod8mgVJVOsJ5M9jRR4DiOfHuo60MNlQ4xE8oYk/g50FMrquoGFt
# lq7KsiWV2CAv0ERi2KDtOtZdfUODdmgI2qOsXEtTwkGIe1Kx4NqEqwAasiiQMTcz
# WwAd9mCsK+Cezs4TJUzeir4xoek/T6mSITUTmjHKUoVe81ZDEQ==
# =Mq/l
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 01 Jun 2026 02:58:35 EDT
# gpg: using RSA key CA473C44D6A09C189A193FCD452B96852B268216
# gpg: Good signature from "Song Gao <gaosong@loongson.cn>" [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: CA47 3C44 D6A0 9C18 9A19 3FCD 452B 9685 2B26 8216
* tag 'pull-loongarch-20260601' of https://github.com/gaosong715/qemu:
target/loongarch/kvm: Include missing exec/target_long.h header
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
linux user patches
A series of patches for linux-user, specifically many FPU fixes in signal
handling code for sh4, mips, ppc and s390x (from Matt Turner), a madvise()
improvement (from me), and qemu header cleanups (from Peter Maydell).
---
v3: Fix build failure due to unknown MADV_COLLAPSE constant in madivise() patch
v2: Dropped the "ARM cortex-m55 program loading fix" and the FPU alpha patch
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCahoKTQAKCRD3ErUQojoP
# XxTMAPwP1hvkA5oV+NCS4y15eTTwycxsEKiSBV0cysz6pkgVGgEA3njxgnnH9iqM
# AxeLtQWJAb3WHNyfDpnj+RLo/xUehQY=
# =jFvz
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 29 May 2026 17:51:09 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-next-pull-request' of https://github.com/hdeller/qemu-hppa:
linux-user: Move cpu_copy() to user-internals.h
linux-user: Move init_main_thread() prototype to user-internals.h
linux-user: Fix typo in function documentation for pgb_addr_set()
linux-user: Implement finer grained madivse() syscall
linux-user/s390x: restore fpu_status rounding mode from FPC on sigreturn
target/sh4: sync fp_status when gdb writes FPSCR
linux-user/sh4: restore FP rounding mode on sigreturn
linux-user/sh4: preserve T/M/Q bits across signal delivery
linux-user/mips: save/restore FCSR across signal delivery
linux-user/ppc: restore fp_status from FPSCR on sigreturn
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
v9fs_co_readdir_many() dispatches do_readdir_many() to a worker thread
that reads V9fsFidState's path.data without holding a rename lock.
A concurrent rename request, e.g. of its parent dir, causes the FID's
absolute path to be altered by freeing the old path string and
assigning a new one. This causes a heap-use-after-free race condition
while do_readdir_many() is still accessing the old object.
This allows a DoS by an unprivileged guest user.
Fix this by wrapping the worker thread dispatch block within a pair of
v9fs_path_read_lock() and v9fs_path_unlock() calls, like it's done at
other places.
Fixes: 2149675b19 ("9pfs: add new function v9fs_co_readdir_many()")
Fixes: CVE-2026-48004
Reported-by: sin99xx <sin99xx@proton.me>
Signed-off-by: sin99xx <sin99xx@proton.me>
[Christian Schoenebeck: add commit log message]
Link: https://lore.kernel.org/qemu-devel/E1wPkYi-000adH-4E@kylie.crudebyte.com
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Add a function to reset the virtqueue descriptor pool state without
reinitializing the device. This is useful for tests that issue a high
number of requests and are limited by the simplified virtio test
driver's descriptor tracking, which decrements num_free but never
increments it back.
The function is safe for synchronous test code where requests are
sent and completed before the next request is issued.
Acked-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/qemu-devel/96cf23eea1204b34443218fe76bd4a5eaf9163e8.1779126034.git.qemu_oss@crudebyte.com
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
This patch mitigates issues with very large absolute paths.
- Add error handling to all v9fs_path_sprintf() calls in
local_name_to_path()
- Update callers of v9fs_fix_path() to check return values.
- When path formatting fails, clunk the affected FIDs to prevent use of
invalid paths.
- Use g_autofree for temporary variables to simplify code.
Even though paths are usually limited to PATH_MAX (typically 4k) on guest,
this limitation can be circumvented by using *at() functions on guest and
creating very deep directory structures. This was a problem for QEMU 9p
server, as it currently tracks the absolute path for each FID internally
that always requires assembly of a (potentially ver large) absolute path.
A true long-term fix would be getting rid of storing an absolute path for
each FID internally. However that would likely be a massive change with
uncertain implications.
This patch therefore just mitigates the problem by immediately clunking
(i.e. closing) all FIDs whose path exceed a limit that we could handle.
As this only accounts to very unusual large absolute paths not ever been
reported on (sane) production machines, this is currently considered an
acceptable mitigation that should only (counter)affect malicious attempts.
Fixes: 2f008a8c97 ("hw/9pfs: Use the correct signed type ...")
Reported-by: Wang Jihe <wangjihe.mail@gmail.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3358
Link: https://lore.kernel.org/qemu-devel/1d11dcbfc95b811dcdb48c6d7f3894d0ebd073a2.1779126034.git.qemu_oss@crudebyte.com
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Update the hexagon cross-compiler Docker container to use toolchain
version 22.1.0, replacing the previous 12.Dec.2023 release.
Changes to accommodate the new toolchain:
- Add libc++1, libc++abi1, libunwind-19 runtime deps for the new
LLVM-based toolchain
- Add zstd for the new .tar.zst archive format
- Update artifact URL domain to artifacts.codelinaro.org
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
The check_rev_gating test is compiled with -mv66, but the final linkage
step does not specify the CPU version. The v22.1.0 toolchain contains a
crt1.o compiled for v68, so the linker resolves the v66 + v68 linkage by
selecting the highest version. The resulting binary then executes v68
instructions without gating, leading to a segfault.
Fix this by passing -cpu v66 to QEMU when running the test, so that the
emulated CPU matches the intended v66 target and the revision gating
mechanism works as expected.
Suggested-by: Matheus Tavares Bernardino <matheus.bernardino@oss.qualcomm.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
We only use cpu_copy() inside linux-user, so we don't need to have
the prototype in qemu.h available to code outside linux-user; move it
to user-internals.h.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Helge Deller <deller@gmx.de>
Signed-off-by: Helge Deller <deller@gmx.de>
The init_main_thread() prototype is needed only by code internal to
linux-user/, so it doesn't need to be in qemu.h (which is also pulled
in by various files outside linux-user/).
Move the prototype to user-internals.h, and give it a documentation
comment.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Helge Deller <deller@gmx.de>
Signed-off-by: Helge Deller <deller@gmx.de>
Although most madvise() values are hints, some are important and are
checked by userspace, especially by security-relevant applications like
BoringSLL. So, return -EINVAL for those functions which we don't emulate.
Signed-off-by: Helge Deller <deller@gmx.de>
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3489
QEMU keeps the s390x floating-point control register (FPC) in env->fpc.
The rounding mode bits [2:0] of FPC are reflected into the derived
env->fpu_status via set_float_rounding_mode(); every architectural
write to FPC goes through HELPER(sfpc) which keeps the two in sync.
restore_sigregs() restored FPC with a direct assignment:
__get_user(env->fpc, &sc->fpregs.fpc);
This wrote env->fpc correctly but never updated env->fpu_status, so on
sigreturn the interrupted code resumed with whatever rounding mode the
signal handler last installed in fpu_status.
Factor the two-step "write fpc + sync fpu_status" logic out of
HELPER(sfpc) into cpu_s390x_load_fpc(), declare it in cpu.h, and call
it from restore_sigregs() in place of the direct assignment.
cpu_s390x_load_fpc() partially reuses the sanity check from
HELPER(sfpc): if the FPC value has an invalid rounding mode or reserved
bits set, it falls back to 0, matching the kernel's fpu_lfpc_safe()
behavior where a corrupt signal frame value causes a specification
exception and 0 is used instead.
HELPER(sfpc) now calls cpu_s390x_load_fpc() after its full
specification-exception check, including the FEAT_FLOATING_POINT_EXT
test that is not needed for the signal restore path.
Fixes: 2941e0fa05 ("linux-user/s390x: Save/restore fpc when handling a signal")
Cc: qemu-stable@nongnu.org
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
sh4_cpu_gdb_write_register() wrote the incoming FPSCR value straight
into env->fpscr, leaving the derived env->fp_status (rounding mode and
flush-to-zero) stale, so a gdb-initiated FPSCR change did not take
effect for subsequent FP operations. Use cpu_load_fpscr() instead, the
same way the adjacent case already uses cpu_write_sr() for SR.
Cc: qemu-stable@nongnu.org
Reviewed-by: Yoshinori Sato <yoshinori.sato@nifty.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
The SH4 FPSCR rounding-mode (RM) and denormal (DN) bits are not held
only in env->fpscr: they are also reflected into the derived
env->fp_status via set_float_rounding_mode()/set_flush_to_zero(). The
guest keeps the two in sync by routing every write to FPSCR through
helper_ld_fpscr().
restore_sigcontext() wrote the saved value straight into env->fpscr and
never touched env->fp_status, so on sigreturn the interrupted code
resumed with whatever FP rounding mode and flush-to-zero setting the
signal handler last installed. (regs->flags = 0 forces the FR/SZ/PR TB
flags to be recomputed, but fp_status is runtime float state, not a TB
flag, so it was left stale.) This is the FP analogue of the T/M/Q bit
problem just fixed for the integer status register.
Factor the FPSCR -> fp_status synchronisation out of helper_ld_fpscr()
into cpu_load_fpscr() and use it from restore_sigcontext() so the
rounding mode round-trips correctly across signal delivery.
Fixes: c3b5bc8ab3 ("SH4: Signal handling for the user space emulator, by Magnus Damm.")
Cc: qemu-stable@nongnu.org
Reviewed-by: Yoshinori Sato <yoshinori.sato@nifty.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
QEMU keeps the SH4 T, M and Q status-register bits outside env->sr, in
the dedicated env->sr_t, env->sr_m and env->sr_q fields; cpu_read_sr()
folds them back into the architectural SR value and cpu_write_sr()
splits them back out.
setup_sigcontext() saved the bare env->sr (so the T/M/Q bits were always
zero in the signal frame) and restore_sigcontext() wrote the value
straight back into env->sr without updating sr_t/sr_m/sr_q. As a result
the T bit was never preserved across signal delivery: on sigreturn the
interrupted code resumed with whatever T value the signal handler last
left behind. Any conditional branch (or addc/subc/rotcl/div1, etc.)
immediately following the interrupted instruction could then take the
wrong path.
This is the cause of the long-standing intermittent failures of the
tests/tcg/multiarch/signals.c test on sh4, which was marked BROKEN. With
a SIGRTMIN timer firing every millisecond across many threads, the race
was hit a few percent of the time and corrupted the guest heap, surfacing
as a SIGSEGV in memset, a malloc assertion, or an rseq registration abort.
Traced on a deterministic rr recording: a cmp/hi set T=0, the timer
signal interrupted the very next instruction (a bf), the handler left
T=1, and the resumed bf took glibc calloc's MORECORE_CLEARS branch,
using the old top-chunk size as the clear length for a freshly split
small chunk and running memset off the end of the heap.
Fix setup_sigcontext()/restore_sigcontext() to use cpu_read_sr() and
cpu_write_sr() so the T, M and Q bits round-trip correctly, and drop the
BROKEN annotation on the sh4 signals test.
Fixes: c3b5bc8ab3 ("SH4: Signal handling for the user space emulator, by Magnus Damm.")
Cc: qemu-stable@nongnu.org
Reviewed-by: Yoshinori Sato <yoshinori.sato@nifty.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
QEMU keeps the MIPS FPU control/status register (FCSR, fcr31) in
env->active_fpu.fcr31. The rounding mode, flush-to-zero (FS), and
NaN-2008 mode bits in fcr31 are reflected into the derived
env->active_fpu.fp_status via set_float_rounding_mode() and friends;
every architectural write to FCSR goes through helper_ctc1() which
calls restore_fp_status() to keep the two in sync.
Both target_sigcontext variants (O32 and N32/N64) have an sc_fpc_csr
field that holds FCSR, but setup_sigcontext() never wrote it and
restore_sigcontext() never read it. As a result:
- The signal frame always delivered sc_fpc_csr == 0 to the handler,
so sigaction(SA_SIGINFO) handlers that inspect the interrupted
context see the wrong FCSR.
- On sigreturn, active_fpu.fcr31 retained whatever value the signal
handler last installed (if any), and active_fpu.fp_status was
never resynced. Interrupted code resumed with the wrong rounding
mode, FS flag, and NaN-2008 semantics.
Fix setup_sigcontext() to save fcr31 into sc_fpc_csr. Fix
restore_sigcontext() to read it back (masked to fcr31_rw_bitmask as
the kernel does) and call cpu_mips_restore_fp_status() to resync
fp_status from the restored fcr31.
Add cpu_mips_restore_fp_status() in target/mips/fpu.c (which already
defines ieee_rm and includes fpu_helper.h), and declare it in cpu.h.
Fixes: 084d0497a0 ("mips-linux-user: Save and restore fpu and dsp from sigcontext")
Cc: qemu-stable@nongnu.org
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
restore_user_regs() restores the PPC FPSCR with a direct assignment:
env->fpscr = (uint32_t) fpscr;
ppc_store_fpscr() exists precisely to write FPSCR and keep the derived
env->fp_status in sync: it calls fpscr_set_rounding_mode() to update
the softfloat rounding mode, and set_float_rebias_overflow/underflow()
to reflect the FP_OE/FP_UE enable bits. The direct assignment bypasses
all of this.
On sigreturn, interrupted code resumes with whatever rounding mode and
overflow/underflow-rebias state the signal handler last installed in
fp_status, rather than the state that was saved at signal delivery.
Replace the direct assign with ppc_store_fpscr(). The FPSCR_MTFS_MASK
applied inside ppc_store_fpscr() only excludes the computed FP_FEX and
FP_VX bits, which it re-derives correctly from the exception and enable
bits in the restored value.
Fixes: bcd4933a23 ("linux-user: ppc signal handling")
Cc: qemu-stable@nongnu.org
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
Zero operands produce a zero high and low product. One operands produce
a copy of the other operand and a zero or sign extension in the high
half.
Fold those cases during TCG optimization so wide-multiply idioms used by
target translators can collapse before code generation.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260520125139.13352-3-philmd@linaro.org>
