Imported by the "Security Issuer Importer" bot, on behalf of the original reporter who disclosed via qemu-security list: * From: `Jihe Wang <wangjihe.mail@gmail.com>` * Date: `22 Mar, 2026` * Message ID: `<CAJDR10FPO6-n-dB-mSCnzcGpKTJShSMPywG-cFG_uDJgV+vtMw@mail.gmail.com>` **NOTE:** the original reporter can not be copied on this issue so cannot view this ticket while it remains marked confidential. If further information is needed about the disclosure, contact the reporter directly. ---- This issue was initially identified with the assistance of an automated tool (a fuzzer), then manually triaged and validated by the reporter. The finding, root cause, and reproducer scenario below were all manually confirmed on a real QEMU build, and the crash was reproduced under AddressSanitizer. Please acknowledge: cnwangjihe Issue summary ------------- I am reporting a heap-use-after-free in QEMU's LSI 53C895A SCSI controller. A guest can program the LSI SCRIPTS engine so that a Block Move DI operation writes an INQUIRY response buffer into the controller's own BAR1 MMIO region. Because BAR1 is byte-access only and its reentrancy guard is explicitly disabled, a byte write to SCNTL1 can synchronously reset the SCSI bus and free the in-flight DMA buffer while `flatview_write_continue()` is still iterating over it. Subsequent iterations then read from freed heap memory. The bug is reproducible on upstream QEMU. Affected component ------------------ - Component: QEMU LSI 53C895A SCSI controller - Primary source file: `hw/scsi/lsi53c895a.c` - Bug type: Heap use-after-free (CWE-416) Validated version and environment --------------------------------- - Upstream tag/describe: `v11.0.0-rc0-28-g8e711856d7` - Upstream commit: `8e711856d7639cbffa51405f2cc2366e3d9e3a23` - QEMU target: `x86_64-softmmu` - Host OS/arch: Linux 5.15.0-171-generic, x86_64, 64-bit - Guest architecture: x86_64, 64-bit - Execution mode: TCG / KVM (both validated) - Sanitizer status: reproduced with `--enable-asan` QEMU build configuration ------------------------ ```sh CC=clang-15 CXX=clang++-15 ../configure \ --target-list=x86_64-softmmu \ --enable-debug --enable-asan ``` QEMU command line used to invoke the guest VM --------------------------------------------- ```sh qemu-system-x86_64 \ -m 512M \ -kernel linux-6.19.9/arch/x86/boot/bzImage \ -initrd rootfs-new.cpio \ -append 'rdinit=/init console=ttyS0 oops=panic panic=1 quiet' \ -monitor /dev/null \ -cpu kvm64,+smep,+smap \ -smp cores=1,threads=1 \ -nographic \ -device lsi53c895a,id=scsi0 \ -drive if=none,id=d1,driver=null-co,read-zeroes=on \ -device scsi-hd,drive=d1,bus=scsi0.0,scsi-id=0,lun=0 ``` Notes: - The backend does not appear security-relevant. `null-co` was used for convenience; the issue is in the LSI controller. Trigger prerequisites and required configuration ------------------------------------------------ - The VM must expose an `lsi53c895a` controller and a reachable SCSI target such as `scsi-hd`. - The reproducer runs from guest userspace and requires `iopl(3)` and `/dev/mem` access. - `CONFIG_STRICT_DEVMEM` was disabled in the guest for convenience so the PoC could map physical memory via `/dev/mem`. Malicious input / reproducer ---------------------------- PoC file: - `poc_lsi_uaf_clean.c` in the attachment. Build: ```sh musl-gcc -static -O2 -o poc_lsi_uaf_clean poc/poc_lsi_uaf_clean.c ``` Reproduce steps: 1. Boot the guest with the QEMU command line shown above. 2. Run `poc_lsi_uaf_clean` inside the guest as root. 3. The PoC locates the LSI PCI function, maps BAR1 and BAR2, and enables PCI memory-space and bus-master access. 4. The PoC programs four SCRIPTS instructions in BAR2: - `SELECT target 0, ATN` - `Block Move MO, 1 byte` - `Block Move CMD, 6 bytes` - `Block Move DI, 36 bytes -> BAR1 - 3` 5. The PoC writes the DSP register to start SCRIPTS execution. 6. QEMU crashes with an ASan-detected heap use-after-free during the byte-wise MMIO write loop. Relevant PoC details: - The command phase issues a standard 6-byte INQUIRY with allocation length 36. - The data-in phase copies those 36 bytes to `BAR1_GPA - 3`. - This offset makes INQUIRY byte 4 land on BAR1 offset `0x01` (`SCNTL1`). - For `scsi-hd`, INQUIRY byte 4 is `0x1f` (`additional_length = 36 - 5`). - `0x1f & 0x08` sets `LSI_SCNTL1_RST`, which synchronously calls `bus_cold_reset()`. Root cause ---------- The vulnerability arises from the combination of three independent design decisions in the LSI controller: ### 1. `disable_reentrancy_guard = true` on BAR1 MMIO QEMU has a generic reentrancy guard (`MemReentrancyGuard`) that blocks MMIO writes arriving while a device is already processing I/O. The LSI controller explicitly disables this guard for its MMIO BAR (`lsi53c895a.c:2356`): ```c s->mmio_io.disable_reentrancy_guard = true; ``` This was added in 2023 as part of the CVE-2023-0330 fix series. The generic guard caused false positives — legitimate LSI DMA completion paths access MMIO registers internally, triggering the guard and breaking normal SCSI operation (observed with Fedora 25 guest). The workaround was to disable the generic guard and add a LSI-specific `reentrancy_level` counter inside `lsi_execute_script()`. The consequence: any DMA write targeting the LSI MMIO BAR is dispatched to register handlers without any reentrancy check. ### 2. `max_access_size = 1` on BAR1 MMIO BAR1's MMIO operations are defined with (`lsi53c895a.c:2140`): ```c .impl = { .min_access_size = 1, .max_access_size = 1 } ``` When `pci_dma_write()` writes a multi-byte buffer to this region, `flatview_write_continue()` in `physmem.c` splits the write into a **byte-by-byte loop**. Each byte is dispatched as a separate `lsi_reg_writeb()` call. The loop holds a stack-local `buf` pointer to the DMA source buffer across all iterations. The consequence: if any single byte's register write handler frees the DMA buffer, subsequent iterations read from freed memory. ### 3. SCNTL1 RST triggers synchronous bus reset Writing bit 3 (`0x08`, `LSI_SCNTL1_RST`) to the SCNTL1 register (offset `0x01`) triggers `bus_cold_reset()` **synchronously** (`lsi53c895a.c:1903`). In TCG mode, `blk_drain()` forces all pending bottom-halves to run immediately, so the entire request cancellation and deallocation chain completes within the same call stack. The consequence: a register write can free in-flight DMA buffers before the enclosing DMA loop finishes reading them. PoC Attack Chain ---------------- ### Step 1: SCRIPTS issue INQUIRY command (synchronous completion) The guest programs four SCRIPTS instructions into BAR2 (Script RAM): | Offset | Instruction | Purpose | |--------|-------------|---------| | 0x00 | `SELECT target 0, ATN` | Select the SCSI disk | | 0x08 | `Block Move MO, 1 byte` | Send IDENTIFY message (LUN 0) | | 0x10 | `Block Move CMD, 6 bytes` | Send INQUIRY CDB (`alloc_len = 36`) | | 0x18 | `Block Move DI, 36 bytes → BAR1 - 3` | **The trigger** | Writing the DSP register starts SCRIPTS execution. The first three instructions complete a standard SCSI INQUIRY sequence. Because INQUIRY is handled entirely by QEMU's `scsi-hd` emulation layer (no real disk I/O), it completes **synchronously** within `lsi_do_command()`. After completion: - `s->current` points to the active `lsi_request` - `s->current->dma_buf` points to the 36-byte INQUIRY response buffer - `s->current->dma_len = 36` ### Step 2: Block Move DI writes INQUIRY data to own MMIO BAR The fourth instruction is Block Move DI with: - byte count = 36 - destination address = `BAR1_GPA - 3` `lsi_execute_script()` dispatches this to `lsi_do_dma()`, which calls (`lsi53c895a.c:663`): ```c lsi_mem_write(s, addr, s->current->dma_buf, count); ``` This calls `pci_dma_write()` → `flatview_write_continue()`. Because the destination overlaps the MMIO BAR, and `max_access_size = 1`, the 36 bytes are written one at a time to consecutive registers: | Byte index | Target address | Register | INQUIRY value | |------------|---------------|----------|---------------| | 0–2 | BAR1 - 3 to BAR1 - 1 | Before MMIO (harmless) | — | | 3 | BAR1 + 0x00 | SCNTL0 | 0x12 | | **4** | **BAR1 + 0x01** | **SCNTL1** | **0x1F** | | 5–35 | BAR1 + 0x02 … 0x20 | SCNTL2 … ISTAT0 | (UAF reads) | ### Step 3: INQUIRY byte 4 = 0x1F triggers SCSI bus reset The standard INQUIRY response for `scsi-hd` has byte 4 = `additional_length = 36 - 5 = 31 = 0x1F` (see `scsi-disk.c:854`). When 0x1F is written to SCNTL1: `0x1F & 0x08 = 0x08` → `LSI_SCNTL1_RST` bit is set → `bus_cold_reset()` is called. The offset `-3` is chosen precisely so that byte 4 of the INQUIRY response (the byte containing 0x1F) lands on register 0x01 (SCNTL1). ### Step 4: Bus reset frees DMA buffer (synchronous) The reset chain executes entirely within the SCNTL1 write handler's call stack: ``` lsi_reg_writeb(SCNTL1, 0x1F) → bus_cold_reset() → scsi_disk_reset() → scsi_device_purge_requests() → blk_drain() // forces sync BH execution → scsi_req_cancel_async() → scsi_req_cancel_complete() → lsi_request_cancelled() → lsi_request_free() // g_free(lsi_request) // s->current = NULL → scsi_req_unref() // refcount → 0 → scsi_free_request() → qemu_vfree(iov_base) // FREES DMA BUFFER → g_free(SCSIRequest) ``` After this returns, the 36-byte INQUIRY response buffer that `flatview_write_continue()` is iterating over has been freed. ### Step 5: UAF — loop continues reading from freed buffer Back in `flatview_write_continue()` (`physmem.c:3289`), the loop resumes with byte index 5. The `buf` pointer is a stack-local variable that still points to the freed allocation. Each subsequent iteration calls `ldn_he_p(buf)` (`physmem.c:3268`) to read from freed heap memory, causing heap UAF. Bytes 5 through 35 (31 bytes) are all UAF reads, each written to a different LSI register (SCNTL2 through ISTAT0). ASAN Output ----------- ``` ==2954514==ERROR: AddressSanitizer: heap-use-after-free on address 0x6250006d2007 at pc 0x565324804c57 bp 0x7fe7dd5f9730 sp 0x7fe7dd5f8f00 READ of size 4 at 0x6250006d2007 thread T2 LLVMSymbolizer: error reading file: No such file or directory #0 0x565324804c56 in __asan_memcpy (u-system-x86_64+0x9e4c56) (BuildId: 4c57) #1 0x56532545ef7b in ldl_he_p include/qemu/bswap.h:278:5 #2 0x5653254658c7 in ldn_he_p include/qemu/bswap.h:487:1 #3 0x5653254655a0 in flatview_write_continue_step system/physmem.c:3268:15 #4 0x565325464e5e in flatview_write_continue system/physmem.c:3299:19 #5 0x56532544668b in flatview_write system/physmem.c:3330:12 #6 0x565325445fce in address_space_write system/physmem.c:3450:18 #7 0x565325446a39 in address_space_rw system/physmem.c:3460:16 #8 0x56532507d15d in dma_memory_rw_relaxed include/system/dma.h:87:12 #9 0x56532507cdf8 in dma_memory_rw include/system/dma.h:130:12 #10 0x56532507cace in pci_dma_rw include/hw/pci/pci_device.h:260:12 #11 0x56532507c578 in pci_dma_write include/hw/pci/pci_device.h:298:12 #12 0x56532507dd5f in lsi_mem_write hw/scsi/lsi53c895a.c:467:9 #13 0x5653250786a4 in lsi_do_dma hw/scsi/lsi53c895a.c:663:9 #14 0x56532507422a in lsi_execute_script hw/scsi/lsi53c895a.c:1289:13 #15 0x56532506e8d2 in lsi_reg_writeb hw/scsi/lsi53c895a.c:2019:13 #16 0x5653250670aa in lsi_mmio_write hw/scsi/lsi53c895a.c:2130:5 #17 0x5653253f6621 in memory_region_write_accessor system/memory.c:491:5 #18 0x5653253f601a in access_with_adjusted_size system/memory.c:567:18 #19 0x5653253f490a in memory_region_dispatch_write system/memory.c:1547:16 #20 0x5653254656a6 in flatview_write_continue_step system/physmem.c:3269:18 #21 0x565325464e5e in flatview_write_continue system/physmem.c:3299:19 #22 0x56532544668b in flatview_write system/physmem.c:3330:12 #23 0x5653254609c1 in subpage_write system/physmem.c:2937:12 #24 0x5653253f6bf8 in memory_region_write_with_attrs_accessor system/memory.2 #25 0x5653253f601a in access_with_adjusted_size system/memory.c:567:18 #26 0x5653253f4af6 in memory_region_dispatch_write system/memory.c:1554:13 #27 0x565324a0a787 in int_st_mmio_leN accel/tcg/cputlb.c:2465:13 #28 0x565324a0a600 in do_st_mmio_leN accel/tcg/cputlb.c:2498:12 #29 0x565324a0a230 in do_st_1 accel/tcg/cputlb.c:2626:9 #30 0x5653249e1962 in do_st1_mmu accel/tcg/cputlb.c:2701:5 #31 0x5653249e16cd in helper_stb_mmu accel/tcg/ldst_common.c.inc:86:5 #32 0x7fe7ff3840ba (/memfd:tcg-jit (deleted)+0x1b900ba) 0x6250006d2007 is located 7 bytes inside of 4096-byte region [0x6250006d2000,0x6250006d3000) freed by thread T2 here: #0 0x5653248056a2 in __interceptor_free (u-system-x86_64+0x9e56a2) (BuildId:) #1 0x5653261e5b7d in qemu_vfree util/memalign.c:90:5 #2 0x56532502a23c in scsi_free_request hw/scsi/scsi-disk.c:133:5 #3 0x565325015766 in scsi_req_unref hw/scsi/scsi-bus.c:1515:13 #4 0x5653250239bf in scsi_device_for_each_req_async_bh hw/scsi/scsi-bus.c:149 #5 0x5653261f1f1f in aio_bh_call util/async.c:173:5 #6 0x5653261f26ba in aio_bh_poll util/async.c:220:13 #7 0x5653261970a7 in aio_poll util/aio-posix.c:720:17 #8 0x565325d42431 in bdrv_do_drained_begin block/io.c:380:9 #9 0x565325d42602 in bdrv_drained_begin block/io.c:393:5 #10 0x565325d0b46d in blk_drain block/block-backend.c:2080:9 #11 0x56532501d023 in scsi_device_purge_requests hw/scsi/scsi-bus.c:1798:5 #12 0x5653250277e2 in scsi_disk_reset hw/scsi/scsi-disk.c:2389:5 #13 0x565325bae170 in do_legacy_reset hw/core/qdev.c:805:5 #14 0x565325bb23c8 in resettable_phase_hold hw/core/resettable.c:162:13 #15 0x565325ba2b0f in bus_reset_child_foreach hw/core/bus.c:97:13 #16 0x565325bb3461 in resettable_child_foreach hw/core/resettable.c:92:9 #17 0x565325bb223a in resettable_phase_hold hw/core/resettable.c:155:5 #18 0x565325bb1ade in resettable_assert_reset hw/core/resettable.c:58:5 #19 0x565325bb1936 in resettable_reset hw/core/resettable.c:45:5 #20 0x565325ba0986 in bus_cold_reset hw/core/bus.c:75:5 #21 0x56532506cd52 in lsi_reg_writeb hw/scsi/lsi53c895a.c:1905:17 #22 0x5653250670aa in lsi_mmio_write hw/scsi/lsi53c895a.c:2130:5 #23 0x5653253f6621 in memory_region_write_accessor system/memory.c:491:5 #24 0x5653253f601a in access_with_adjusted_size system/memory.c:567:18 #25 0x5653253f490a in memory_region_dispatch_write system/memory.c:1547:16 #26 0x5653254656a6 in flatview_write_continue_step system/physmem.c:3269:18 #27 0x565325464e5e in flatview_write_continue system/physmem.c:3299:19 #28 0x56532544668b in flatview_write system/physmem.c:3330:12 #29 0x565325445fce in address_space_write system/physmem.c:3450:18 previously allocated by thread T2 here: #0 0x5653248064b7 in posix_memalign (u-system-x86_64+0x9e64b7) (BuildId: 4c5) #1 0x5653261e577b in qemu_try_memalign util/memalign.c:53:11 #2 0x5653261e5a7c in qemu_memalign util/memalign.c:73:15 #3 0x565325d4f669 in qemu_blockalign block/io.c:3358:12 #4 0x565325d17019 in blk_blockalign block/block-backend.c:2368:12 #5 0x565325030713 in scsi_disk_emulate_command hw/scsi/scsi-disk.c:2058:27 #6 0x5653250149a6 in scsi_req_enqueue hw/scsi/scsi-bus.c:1027:10 #7 0x5653250792de in lsi_do_command hw/scsi/lsi53c895a.c:880:9 #8 0x565325074302 in lsi_execute_script hw/scsi/lsi53c895a.c:1294:13 #9 0x56532506e8d2 in lsi_reg_writeb hw/scsi/lsi53c895a.c:2019:13 #10 0x5653250670aa in lsi_mmio_write hw/scsi/lsi53c895a.c:2130:5 #11 0x5653253f6621 in memory_region_write_accessor system/memory.c:491:5 #12 0x5653253f601a in access_with_adjusted_size system/memory.c:567:18 #13 0x5653253f490a in memory_region_dispatch_write system/memory.c:1547:16 #14 0x5653254656a6 in flatview_write_continue_step system/physmem.c:3269:18 #15 0x565325464e5e in flatview_write_continue system/physmem.c:3299:19 #16 0x56532544668b in flatview_write system/physmem.c:3330:12 #17 0x5653254609c1 in subpage_write system/physmem.c:2937:12 #18 0x5653253f6bf8 in memory_region_write_with_attrs_accessor system/memory.2 #19 0x5653253f601a in access_with_adjusted_size system/memory.c:567:18 #20 0x5653253f4af6 in memory_region_dispatch_write system/memory.c:1554:13 #21 0x565324a0a787 in int_st_mmio_leN accel/tcg/cputlb.c:2465:13 #22 0x565324a0a600 in do_st_mmio_leN accel/tcg/cputlb.c:2498:12 #23 0x565324a0a230 in do_st_1 accel/tcg/cputlb.c:2626:9 #24 0x5653249e1962 in do_st1_mmu accel/tcg/cputlb.c:2701:5 #25 0x5653249e16cd in helper_stb_mmu accel/tcg/ldst_common.c.inc:86:5 #26 0x7fe7ff3840ba (/memfd:tcg-jit (deleted)+0x1b900ba) Thread T2 created by T0 here: #0 0x5653247ee6dc in pthread_create (u-system-x86_64+0x9ce6dc) (BuildId: 4c5) #1 0x5653261a874e in qemu_thread_create util/qemu-thread-posix.c:454:11 #2 0x565324a1818f in mttcg_start_vcpu_thread accel/tcg/tcg-accel-ops-mttcg.c5 #3 0x5653253d5530 in qemu_init_vcpu system/cpus.c:726:5 #4 0x5653259b42d2 in x86_cpu_realizefn target/i386/cpu.c:10161:5 #5 0x565325baff5b in device_set_realized hw/core/qdev.c:523:13 #6 0x565325bc478d in property_set_bool qom/object.c:2376:5 #7 0x565325bbf0cb in object_property_set qom/object.c:1450:5 #8 0x565325bcc839 in object_property_set_qobject qom/qom-qobject.c:28:10 #9 0x565325bbfb4f in object_property_set_bool qom/object.c:1520:15 #10 0x565325bacf0e in qdev_realize hw/core/qdev.c:276:12 #11 0x5653258dc72e in x86_cpu_new hw/i386/x86-common.c:63:5 #12 0x5653258dc5e2 in x86_cpus_init hw/i386/x86-common.c:114:9 #13 0x5653258d66df in pc_init1 hw/i386/pc_piix.c:187:5 #14 0x5653258d5fdb in pc_i440fx_init hw/i386/pc_piix.c:393:5 #15 0x5653258d58b4 in pc_i440fx_machine_11_0_init hw/i386/pc_piix.c:436:1 #16 0x565324bbcf3b in machine_run_board_init hw/core/machine.c:1678:5 #17 0x5653253bae90 in qemu_init_board system/vl.c:2717:5 #18 0x5653253ba9a4 in qmp_x_exit_preconfig system/vl.c:2811:5 #19 0x5653253c047f in qemu_init system/vl.c:3849:9 #20 0x565325fb020c in main system/main.c:71:5 #21 0x7fe883b00d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 ``` Please let me know if you would like any additional details. [poc_lsi_uaf_clean.c](/uploads/543c2a3ea1578a3300f53341294c035c/poc_lsi_uaf_clean.c)