Branch: refs/heads/staging-10.1
Home: https://github.com/qemu/qemu
Commit: 3a7b0cd6a6051c920f17c0798ba0be970c1e8869
https://github.com/qemu/qemu/commit/3a7b0cd6a6051c920f17c0798ba0be970c1e8869
Author: rail5 <[email protected]>
Date: 2026-03-13 (Fri, 13 Mar 2026)
Changed paths:
M target/loongarch/cpu.c
M target/loongarch/cpu.h
M target/loongarch/tcg/tlb_helper.c
Log Message:
-----------
target/loongarch: Preserve PTE permission bits in LDPTE
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: [email protected]
Signed-off-by: rail5 (Andrew S. Rightenburg) <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
Reviewed-by: Song Gao <[email protected]>
Signed-off-by: Song Gao <[email protected]>
(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 <[email protected]>
Commit: 730e6cb5547b85a84f1c5585fb0f17920559b50f
https://github.com/qemu/qemu/commit/730e6cb5547b85a84f1c5585fb0f17920559b50f
Author: rail5 <[email protected]>
Date: 2026-03-13 (Fri, 13 Mar 2026)
Changed paths:
M target/loongarch/cpu.c
Log Message:
-----------
target/loongarch: Avoid recursive PNX exception on CSR_BADI fetch
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: [email protected]
Signed-off-by: rail5 (Andrew S. Rightenburg) <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
Reviewed-by: Song Gao <[email protected]>
Signed-off-by: Song Gao <[email protected]>
(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 <[email protected]>
Commit: 561ddd82ea06e3ef78ca043f3929924df012a2f5
https://github.com/qemu/qemu/commit/561ddd82ea06e3ef78ca043f3929924df012a2f5
Author: Hanna Czenczek <[email protected]>
Date: 2026-03-13 (Fri, 13 Mar 2026)
Changed paths:
M block/export/fuse.c
Log Message:
-----------
fuse: Copy write buffer content before polling
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: [email protected]
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit a3fcbca0ef643a8aecf354bdeb08b1d81e5b33e7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 82600ca4073c4dcb20aa348b8c1f5b2db21683a7
https://github.com/qemu/qemu/commit/82600ca4073c4dcb20aa348b8c1f5b2db21683a7
Author: Paolo Bonzini <[email protected]>
Date: 2026-03-13 (Fri, 13 Mar 2026)
Changed paths:
M hw/hyperv/syndbg.c
Log Message:
-----------
hyperv/syndbg: check length returned by cpu_physical_memory_map()
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 <https://github.com/1seal>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Fixes: CVE-2026-3842
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 4f28b87fdd24df2049626106b7c24d0180952115)
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/4ee1a82620f0...82600ca4073c
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
