I can trigger a host-side AddressSanitizer crash in current QEMU master through the LoongArch `virt` machine's DINTC MMIO interface when DMSI is enabled. The issue is in `loongarch_dintc_mem_write()`. The DINTC write handler derives `cpu_num` directly from guest-controlled MMIO address bits, then uses it without validating that the CPU exists or that the index is within the DINTC `s->cpu[]` array: ```c static void loongarch_dintc_mem_write(void *opaque, hwaddr addr, uint64_t val, unsigned size) { int irq_num, cpu_num = 0; LoongArchDINTCState *s = LOONGARCH_DINTC(opaque); uint64_t msg_addr = addr + VIRT_DINTC_BASE; CPUState *cs; cpu_num = FIELD_EX64(msg_addr, MSG_ADDR, CPU_NUM); cs = cpu_by_arch_id(cpu_num); irq_num = FIELD_EX64(msg_addr, MSG_ADDR, IRQ_NUM); async_run_on_cpu(cs, do_set_vcpu_dintc_irq, RUN_ON_CPU_HOST_INT(irq_num)); qemu_set_irq(s->cpu[cpu_num].parent_irq, 1); } ``` `CPU_NUM` is encoded in bits `[19:12]` of the DINTC message address. A guest can write to the DINTC MMIO page with `CPU_NUM=0xff` on a VM that only has one vCPU. In that case `cpu_by_arch_id(0xff)` returns `NULL`, and QEMU passes the NULL `CPUState *` to `async_run_on_cpu()`, crashing in the host. The following `s->cpu[cpu_num]` access is also indexed with the same unchecked guest-controlled value. ## Environment Reproduced on current master: - QEMU commit: `b83371668192a705b878e909c5ae9c1233cbd5fb` - build: `../configure --target-list=loongarch64-softmmu --enable-asan --disable-werror` - machine used by reproducer: `virt` - relevant machine option: `dmsi=on` - relevant CPU option: `la464,msgint=on` ## Steps to reproduce Build an ASan QEMU: ```text mkdir build-asan cd build-asan ../configure --target-list=loongarch64-softmmu --enable-asan --disable-werror ninja -j$(nproc) qemu-system-loongarch64 cd .. ``` Save the following as `repro_loongarch_dintc_cpuid_oob.sh`: ```sh #!/usr/bin/env bash set -euo pipefail QEMU=${QEMU:-./build-asan/qemu-system-loongarch64} ASAN_OPTIONS="${ASAN_OPTIONS:-abort_on_error=1:halt_on_error=1:detect_leaks=0:symbolize=1}" \ "$QEMU" \ -display none \ -nodefaults \ -machine virt,accel=qtest,dmsi=on \ -cpu la464,msgint=on \ -m 128M \ -smp 1 \ -qtest stdio <<'QTEST' # VIRT_DINTC_BASE is 0x2fe00000. # CPU_NUM is encoded in MSG_ADDR bits [19:12]. # Address 0x2feff000 selects CPU_NUM=0xff, outside this 1-vCPU VM. writeq 0x2feff000 0x1 QTEST ``` Run: ```text chmod +x repro_loongarch_dintc_cpuid_oob.sh ./repro_loongarch_dintc_cpuid_oob.sh ``` ## ASan output ```text ERROR: AddressSanitizer: SEGV on unknown address 0x0000000001ec The signal is caused by a READ memory access. Hint: address points to the zero page. #0 qemu_mutex_lock_impl ../util/qemu-thread-posix.c:107 #1 queue_work_on_cpu ../cpu-common.c:135 #2 async_run_on_cpu ../cpu-common.c:178 #3 loongarch_dintc_mem_write ../hw/intc/loongarch_dintc.c:58 #4 memory_region_write_accessor ../system/memory.c:492 #5 access_with_adjusted_size ../system/memory.c:568 #6 memory_region_dispatch_write ../system/memory.c:1550 #7 flatview_write_continue_step ../system/physmem.c:3263 #8 flatview_write_continue ../system/physmem.c:3293 #9 flatview_write ../system/physmem.c:3324 #10 address_space_write ../system/physmem.c:3444 #11 qtest_process_command ../system/qtest.c:540 SUMMARY: AddressSanitizer: SEGV ../util/qemu-thread-posix.c:107 in qemu_mutex_lock_impl ABORTING ``` ## Suggested fix Validate the guest-controlled DINTC `CPU_NUM` before using it. The handler should reject/log invalid CPU numbers if no matching `CPUState` exists or if the value is outside the DINTC CPU array. For example: ```c cpu_num = FIELD_EX64(msg_addr, MSG_ADDR, CPU_NUM); irq_num = FIELD_EX64(msg_addr, MSG_ADDR, IRQ_NUM); if (cpu_num >= s->num_cpu) { qemu_log_mask(LOG_GUEST_ERROR, "loongarch-dintc: invalid cpu number %d\n", cpu_num); return; } cs = cpu_by_arch_id(cpu_num); if (!cs) { qemu_log_mask(LOG_GUEST_ERROR, "loongarch-dintc: no CPU for arch id %d\n", cpu_num); return; } async_run_on_cpu(cs, do_set_vcpu_dintc_irq, RUN_ON_CPU_HOST_INT(irq_num)); qemu_set_irq(s->cpu[cpu_num].parent_irq, 1); ``` If LoongArch CPU arch IDs are not guaranteed to be identical to the `s->cpu[]` array index, it may be safer to look up the matching `DINTCCore` by `arch_id` and then use that slot, rather than indexing `s->cpu[cpu_num]` directly.