qemu/qemu.git, branch stable-10.1

Update version for 10.1.5 release

2026-03-17T08:32:30+00:00

Signed-off-by: Michael Tokarev

hyperv/syndbg: check length returned by cpu_physical_memory_map()

2026-03-13T07:16:27+00:00

If cpu_physical_memory_map() returns a length shorter than the one that was passed into the function, writing the full out_len bytes causes an access beyond the memory allocated to the guest; or in the case of the MMIO bounce buffer, an out-of-bounds access in a heap-allocated object. Add a check similar to the one already in handle_send_msg(), and take the occasion to remove repeated computations of recv_byte_count + UDP_PKT_HEADER_SIZE and clarify that the code does not write past out_len bytes. Reported-by: Oleh Konko Reviewed-by: Daniel P. Berrangé Fixes: CVE-2026-3842 Signed-off-by: Paolo Bonzini (cherry picked from commit 4f28b87fdd24df2049626106b7c24d0180952115) Signed-off-by: Michael Tokarev

fuse: Copy write buffer content before polling

2026-03-13T07:16:27+00:00

aio_poll() in I/O functions can lead to nested read_from_fuse_export() calls, overwriting the request buffer's content. The only function affected by this is fuse_write(), which therefore must use a bounce buffer or corruption may occur. Note that in addition we do not know whether libfuse-internal structures can cope with this nesting, and even if we did, we probably cannot rely on it in the future. This is the main reason why we want to remove libfuse from the I/O path. I do not have a good reproducer for this other than: $ dd if=/dev/urandom of=image bs=1M count=4096 $ dd if=/dev/zero of=copy bs=1M count=4096 $ touch fuse-export $ qemu-storage-daemon \ --blockdev file,node-name=file,filename=copy \ --export \ fuse,id=exp,node-name=file,mountpoint=fuse-export,writable=true \ & Other shell: $ qemu-img convert -p -n -f raw -O raw -t none image fuse-export $ killall -SIGINT qemu-storage-daemon $ qemu-img compare image copy Content mismatch at offset 0! (The -t none in qemu-img convert is important.) I tried reproducing this with throttle and small aio_write requests from another qemu-io instance, but for some reason all requests are perfectly serialized then. I think in theory we should get parallel writes only if we set fi->parallel_direct_writes in fuse_open(). In fact, I can confirm that if we do that, that throttle-based reproducer works (i.e. does get parallel (nested) write requests). I have no idea why we still get parallel requests with qemu-img convert anyway. Also, a later patch in this series will set fi->parallel_direct_writes and note that it makes basically no difference when running fio on the current libfuse-based version of our code. It does make a difference without libfuse. So something quite fishy is going on. I will try to investigate further what the root cause is, but I think for now let's assume that calling blk_pwrite() can invalidate the buffer contents through nested polling. Cc: qemu-stable@nongnu.org Reviewed-by: Kevin Wolf Signed-off-by: Hanna Czenczek Message-ID: <20260309150856.26800-2-hreitz@redhat.com> Reviewed-by: Kevin Wolf Signed-off-by: Kevin Wolf (cherry picked from commit a3fcbca0ef643a8aecf354bdeb08b1d81e5b33e7) Signed-off-by: Michael Tokarev

target/loongarch: Avoid recursive PNX exception on CSR_BADI fetch

2026-03-13T07:16:00+00:00

loongarch_cpu_do_interrupt() updates CSR_BADI by fetching the faulting instruction with cpu_ldl_code_mmu(). For a PNX exception (instruction fetch prohibited by NX), fetching the instruction at env->pc will fault with PNX again. This can lead to an infinite exception loop. Treat PNX like other instruction-fetch exceptions (PIF/ADEF) and do not update CSR_BADI for it. -Fixes: 410dfbf620a ("target/loongarch: Move TCG specified functions to tcg_cpu.c") Fixes: d2cba6f7cea9 ("target/loongarch: Add other core instructions support") Cc: qemu-stable@nongnu.org Signed-off-by: rail5 (Andrew S. Rightenburg) Reviewed-by: Bibo Mao Reviewed-by: Song Gao Signed-off-by: Song Gao (cherry picked from commit db2325f79481fab87211e5a287580d753f582cb8) (Mjt: back-port to 10.1.x across v10.1.0-1187-g410dfbf620 "target/loongarch: Move TCG specified functions to tcg_cpu.c") (fixing the Fixes: tag) Signed-off-by: Michael Tokarev

target/loongarch: Preserve PTE permission bits in LDPTE

2026-03-13T07:15:33+00:00

The LDPTE helper loads a page table entry (or huge page entry) from guest memory and currently applies the PALEN mask to the whole 64-bit value. That mask is intended to constrain the physical address bits, but masking the full entry also clears upper permission bits in the PTE, including NX (bit 62). As a result, LoongArch TCG can incorrectly allow instruction fetches from NX mappings when translation is driven through software page-walk. Fix this by masking only the PPN/address field with PALEN while preserving permission bits, and by clearing any non-architectural (software) bits using a hardware PTE mask. LDDIR is unchanged since it returns the base address of the next page table level. Reported at: https://gitlab.com/qemu-project/qemu/-/issues/3319 -Fixes: 56599a705f2 ("target/loongarch: Introduce loongarch_palen_mask()") Fixes: f757a2cd6948 ("target/loongarch: Add LoongArch interrupt and exception handler") Cc: qemu-stable@nongnu.org Signed-off-by: rail5 (Andrew S. Rightenburg) Reviewed-by: Bibo Mao Reviewed-by: Song Gao Signed-off-by: Song Gao (cherry picked from commit 2d877bc02a3b94998cbdd784d194c173d308a98a) (Mjt: backport to 10.1.x which lacks v10.2.0-1568-g56599a705f "target/loongarch: Introduce loongarch_palen_mask()") (fixing the Fixes: tag) Signed-off-by: Michael Tokarev

hw/net/npcm_gmac: Catch accesses off the end of the register array

2026-03-11T13:41:49+00:00

In the npcm_gmac device, we create the iomem MemoryRegion with a size of 8KB, but NPCM_GMAC_NR_REGS is only 0x1060 / 4. This means there's a range of offsets that the guest can access that don't have gmac->regs[] entries. We weren't catching this, so the guest could get us to index off the end of the regs array. Catch and log these invalid accesses. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3316 Signed-off-by: Peter Maydell Reviewed-by: Philippe Mathieu-Daudé Message-ID: <20260306154016.2194091-1-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé (cherry picked from commit 550391c7134d295d73b2b0e7a1111a922b78c13c) Signed-off-by: Michael Tokarev

linux-user: fix TIOCGSID ioctl

2026-03-11T13:41:49+00:00

TIOCGSID is IOC_R, not IOC_W. Signed-off-by: Andreas Schwab Reviewed-by: Helge Deller Signed-off-by: Helge Deller (cherry picked from commit 6a1221614fd9344a22cafea78e48d6ded95f317d) Signed-off-by: Michael Tokarev

tests/tcg/multiarch/test-mmap: Check mmaps beyond reserved_va

2026-03-11T13:41:49+00:00

Unfixed mmap calls where start > reserved_va or the max guest addr should have a valid result. Signed-off-by: Bingwu Zhang Signed-off-by: Helge Deller (cherry picked from commit c865b6bce5d0c882b86fb7c3512174cdaf235017) Signed-off-by: Michael Tokarev

bsd-user: Deal with mmap where start > reserved_va

2026-03-11T13:41:49+00:00

Fixes: f12294b5bd21 ("bsd-user: Use page_find_range_empty for mmap_find_vma_reserved") Signed-off-by: Bingwu Zhang Reviewed-by: Helge Deller Reviewed-by: Warner Losh Signed-off-by: Helge Deller (cherry picked from commit e8e7d1f97785be2fd81fc520e0c7b9d228c10a56) Signed-off-by: Michael Tokarev

linux-user: Deal with mmap where start > reserved_va

2026-03-11T13:41:49+00:00

Fixes: 4c13048e02d9 ("linux-user: Use page_find_range_empty for mmap_find_vma_reserved") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3310 Signed-off-by: Bingwu Zhang Reviewed-by: Helge Deller Signed-off-by: Helge Deller (cherry picked from commit f2813e13fe910e01127271a87177a477b9438bc6) Signed-off-by: Michael Tokarev