qemu/qemu.git, branch v10.2.4

Update version for 10.2.4 release

2026-06-25T11:09:07+00:00

Signed-off-by: Michael Tokarev

linux-user: Fix AT_PHDR when program headers are relocated into their own segment

2026-06-24T13:35:22+00:00

When a binary is patched or relocated such that the program header table is moved into a separate PT_LOAD segment (rather than sitting at the start of the first loadable segment), QEMU's AT_PHDR auxv entry becomes incorrect. The loader was computing AT_PHDR as load_addr + e_phoff, which assumes the headers are mapped 1:1 from file offset 0. This breaks when the headers are elsewhere. The Linux kernel instead locates the PT_LOAD segment that contains e_phoff, then computes the in-memory address as p_vaddr + (e_phoff - p_offset). This correctly handles relocated headers. Fix by: 1. Add phdr_addr field to image_info to cache the resolved address. 2. Initialize to load_addr + e_phoff (fallback for headers outside any PT_LOAD). 3. In the PT_LOAD mapping loop, detect if the segment contains e_phoff and override with the segment-relative address. 4. Use info->phdr_addr for AT_PHDR instead of the incorrect formula. Signed-off-by: Akshit Yadav Reviewed-by: Helge Deller (cherry picked from commit 156e536a7b9700018aaa2437072c14e3376340a7) Signed-off-by: Michael Tokarev

hw/pci: Replace assert with bounds check and return

2026-06-24T13:35:22+00:00

As reported in https://gitlab.com/qemu-project/qemu/-/work_items/3334, callers of 'pci_host_config_{read,write}_common' can pass length as 8, causing an assert failure The original issue with pnv_phb3 triggering the assert was fixed in a previous commit Instead of asserting on invalid length, check if the length is valid (<=4), otherwise return (with the failure error code in read) Reported-by: Zexiang Zhang Signed-off-by: Aditya Gupta Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin Message-Id: <20260326190438.734239-3-adityag@linux.ibm.com> (cherry picked from commit c7209c56718107fefd5deae140a450954d31ff2b) Signed-off-by: Michael Tokarev

ppc/pnv_phb3: Error out on invalid config access

2026-06-24T13:35:22+00:00

PHB in Power8 supports 8 byte registers, and hence the ops structure allows accessing of 8 bytes in 'pnv_phb3_reg_ops' Both 'pnv_phb3_reg_read' & 'pnv_phb3_reg_write' pass the arguments as is to 'pnv_phb3_config_{read,write}', if offset is PHB_CONFIG_DATA. This when called with size as 8, causes following assert failure in 'pci_host_config_read_common' & 'pci_host_config_write_common': assert(len <= 4); Validate that size is <=4, before jumping to pci_host_config_{read,write}_common Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3334 Reported-by: Zexiang Zhang Fixes: 9ae1329ee2fe ("ppc/pnv: Add models for POWER8 PHB3 PCIe Host bridge") Signed-off-by: Aditya Gupta Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin Message-Id: <20260326190438.734239-2-adityag@linux.ibm.com> (cherry picked from commit 218109781209f9d77242b2cdf743acac8bc3b893) Signed-off-by: Michael Tokarev

linux-user/xtensa: fix unlock of uninitialized frame pointer on sigreturn

2026-06-24T13:35:22+00:00

If lock_user_struct fails, frame is uninitialized but the badframe label unconditionally calls unlock_user_struct on it. Handle the lock failure inline so badframe is only reached with a valid lock. Signed-off-by: Matt Turner Cc: qemu-stable@nongnu.org Reviewed-by: Helge Deller Signed-off-by: Helge Deller (cherry picked from commit 54e08dbe8f2aeca57e3b1a5eab09a9fec88c1c67) Signed-off-by: Michael Tokarev

linux-user/xtensa: save/restore FP registers across signal delivery

2026-06-24T13:35:22+00:00

Add support for saving and restoring f0-f15 across signal delivery. The target_xtensa_xtregs_fp struct carries 32-bit f-regs for cores with XTENSA_OPTION_FP_COPROCESSOR; target_xtensa_xtregs_dfp carries 64-bit f-regs for cores with XTENSA_OPTION_DFP_COPROCESSOR. Lock the xtregs region via lock_user before reading on sigreturn, since sc_xtregs is a user-space pointer that may lie outside the locked sigframe. Signed-off-by: Matt Turner Reviewed-by: Richard Henderson Signed-off-by: Helge Deller (cherry picked from commit 6858e3a71cc41510937bec0950eb4e42e33ba5f2) Signed-off-by: Michael Tokarev

target/xtensa: add cpu_set_fcr/fsr helpers to sync fp_status

2026-06-24T13:35:22+00:00

Factor FCR→fp_status and FSR→fp_status synchronisation out of the wur_fpu{2k,}_fcr/wur_fpu_fsr helpers into cpu_set_fcr(), cpu_set_fsr(), and cpu_get_fsr(). Signal delivery code needs to restore the FP rounding mode and exception flags without duplicating the flag-mapping tables. cpu_set_fcr() applies the union mask 0xfffff07f (superset of the wur_fpu_fcr mask 0x0000007f and the wur_fpu2k_fcr mask 0xfffff07f) so that FCR bits valid only on fpu2k configs are preserved while MBZ bits 7-11 are always cleared. Signed-off-by: Matt Turner Reviewed-by: Richard Henderson Signed-off-by: Helge Deller (cherry picked from commit 7e859bacea09a626c239f14ab9c01f13d5225723) Signed-off-by: Michael Tokarev

ui/sdl2: Set GL ES profile before creating initial GL context

2026-06-24T13:35:14+00:00

When the user selects GLES via '-display sdl,gl=es', we need to set SDL_GL_CONTEXT_PROFILE_MASK to SDL_GL_CONTEXT_PROFILE_ES before calling SDL_GL_CreateContext(). This ensures SDL_GL_LoadLibrary() loads the correct GLES driver instead of the desktop OpenGL driver. Fix the below issue: qemu-system-aarch64: /usr/src/debug/libepoxy /1.5.10/src/dispatch_common.c:872: epoxy_get_proc_address: Assertion `0 && "Couldn't find current GLX or EGL context.\n"' failed. sdl2_gl_create_context() already sets the profile mask correctly for ES mode, but the initial context created in sdl2_window_create() is missing the same treatment. Fixes:da3f7a3ab9ea0091955b58f8909dfcee01f4043e ("ui/sdl: try to instantiate the matching opengl renderer") Signed-off-by: ryan.zhang@nxp.com Reviewed-by: Marc-André Lureau Message-ID: (cherry picked from commit 490a3e1867f025c68fa13db766b5c8da16c6eca4) Signed-off-by: Michael Tokarev

hw/9pfs: reject . and .. in Twstat rename

2026-06-19T05:47:15+00:00

The other Trename and Trenameat handlers already reject "." and ".." as new name on rename requests by returning -EISDIR in this case. The legacy Twstat rename handler is missing this validation. While passing "." or ".." does not trigger a crash as fixed by the previous patch (since the fs backend driver's system calls handle these gracefully), it creates a behavioral inconsistency, as it is semantically meaningless to rename a file to a directory reference in the first place. Fix this by rejecting "." and ".." in Twstat rename handler with -EISDIR to match behavior of Trename and Trenameat handlers. Fixes: 8cf89e007a ("virtio-9p: Add P9_TWSTAT support") Link: https://lore.kernel.org/qemu-devel/662333331d371c6c343c8091161de8eaa121880e.1780072238.git.qemu_oss@crudebyte.com Signed-off-by: Christian Schoenebeck (cherry picked from commit 08750e31fcdccf5352dc3b44475ed5ba6bc80221) Signed-off-by: Michael Tokarev

hw/9pfs: fix abort due to illegal name with Twstat rename

2026-06-19T05:47:15+00:00

The legacy Twstat 9p request can be used to rename files and directories. Unlike the other, more recent rename requests like Trename and Trenameat, Twstat does not validate the submitted new name before passing it to v9fs_complete_rename(). A priviliged guest user with direct communication access to 9p server could pass a string containing '/' as new name, which causes an assertion fault (DoS) in local_name_to_path(). Fix this by rejecting such strings by checking the client supplied new name with name_is_illegal(), similar to how Trename and Trenameat handlers do already. Reported-by: Feifan Qian Fixes: 8cf89e007a ("virtio-9p: Add P9_TWSTAT support") Link: https://lore.kernel.org/qemu-devel/ba09716828e82992f9d8cac7f00eee0bc1c43c61.1780072238.git.qemu_oss@crudebyte.com Signed-off-by: Christian Schoenebeck (cherry picked from commit 7f5445e7e4050cc117ed4b137bb7dd1474e49d57) Signed-off-by: Michael Tokarev