Imported by the "Security Issuer Importer" bot, on behalf of the original reporter who disclosed via qemu-security list: * From: `강희찬 <gganji11@naver.com>` * Date: `10 May, 2026` * Message ID: `<b610dd678b6c4cd471bf2858ea9474f@cweb017.nm>` **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. ---- Disclosure note: this issue was found with LLM-assisted source review and then manually validated with local ASAN, qtest, and Linux guest reproducers before reporting. I am reporting a guest-triggerable host memory corruption issue in QEMU's SM501 PCI display device model. I confirmed host out-of-bounds read/write and a guest-triggered command-execution proof on an x86_64 `q35`machine with a PCI `sm501`device. The final proof is not qtest-only: it boots a Linux guest initramfs, runs a static guest binary as root, maps the SM501 PCI BARs via the guest's normal `/sys/bus/pci/devices/.../resourceN`files, and performs only guest-accessible PCI resource/MMIO/VRAM operations. It does not use `/proc/<qemu-pid>/maps`, `/proc/<qemu-pid>/mem`, gdb, QMP, or monitor commands in the exploit path. ## Summary `hw/display/sm501.c`allocates `s->local_mem`according to the configured SM501 local memory size during device initialization. After initialization, the guest can write the emulated `SM501_DRAM_CONTROL` register and change: ```c s->local_mem_size_index = (value >> 13) & 0x7; ``` The SM501 2D engine then uses the mutable `get_local_mem_size(s)`value for source and destination bounds checks. With a valid small PCI configuration such as `vram-size=2097152`, the backing RAMBlock is 2 MiB, but the guest can select the 64 MiB emulated size at runtime. Later SM501 2D operations then access: ```text s->local_mem + guest_controlled_26bit_offset ``` beyond the allocated RAMBlock. I confirmed: -host out-of-bounds read through SM501 2D BitBlt; -host out-of-bounds write through SM501 2D Rectangle Fill / BitBlt; -guest-side address discovery using only the SM501 OOB read primitive; -overwrite of libpixman's implementation pointer using only the SM501 OOB write primitive; -QEMU host process command execution with marker command: ```text id>/tmp/sm501_rce;exit 1 ``` The proof is a local exploitability demonstration, not a portable weaponized exploit. ## Tested Version Upstream QEMU commit: ```text ac0cc20ad2fe0b8df2e5d9458e90a095ac711ab1 ``` Version string: ```text QEMU emulator version 11.0.50 (v11.0.0-578-gac0cc20ad2-dirty) ``` Tested target/build: ```text target-list=x86_64-softmmu machine=q35 accelerator=KVM device=sm501,vram-size=2097152,x-pixman=7,addr=03.0 guest kernel=Ubuntu 5.15.0-174-generic ``` I enabled SM501 in the local x86_64 build with: ```text configs/devices/x86_64-softmmu/sm501.mak include default.mak CONFIG_SM501=y ``` `hw/display/sm501.c`was unmodified during validation. ## Affected Code Local memory size table: ```text hw/display/sm501.c:449-456 static const uint32_t sm501_mem_local_size[] = { [0] = 4 * MiB, [1] = 8 * MiB, [2] = 16 * MiB, [3] = 32 * MiB, [4] = 64 * MiB, [5] = 2 * MiB, }; ``` Initial allocation uses the configured initial size: ```text hw/display/sm501.c:1902 s->local_mem_size_index = get_local_mem_size_index(local_mem_bytes) hw/display/sm501.c:1905-1908 memory_region_init_ram(... get_local_mem_size(s) ...) s->local_mem = memory_region_get_ram_ptr(...) ``` PCI device accepts a configurable `vram-size`: ```text hw/display/sm501.c:2136 sm501_init(&s->state, DEVICE(dev), s->vram_size) hw/display/sm501.c:2149 DEFINE_PROP_UINT32("vram-size", SM501PCIState, vram_size, 64 * MiB) ``` Guest-controlled runtime size mutation: ```text hw/display/sm501.c:1023-1025 case SM501_DRAM_CONTROL: s->local_mem_size_index = (value >> 13) & 0x7; /* TODO : check validity of size change */ ``` 2D bounds checks use the mutable size rather than the allocated RAMBlock size: ```text hw/display/sm501.c:730-734 destination bounds check uses get_local_mem_size(s) hw/display/sm501.c:755-760 source bounds check uses get_local_mem_size(s) ``` Unsafe host pointer use after those checks: ```text hw/display/sm501.c:821-822 stn_he_p(&s->local_mem[dst_base + di], ..., ldn_he_p(&s->local_mem[src_base + si], ...)) hw/display/sm501.c:865-866 pixman_blt((uint32_t *)&s->local_mem[src_base], (uint32_t *)&s->local_mem[dst_base], ...) hw/display/sm501.c:890 memcpy(&d[i], &sp[j], width * bypp) hw/display/sm501.c:909-911 pixman_fill((uint32_t *)&s->local_mem[dst_base], ...) hw/display/sm501.c:920 stn_he_p(&d[i], bypp, color) ``` ## Reproduction Build QEMU with PCI SM501 enabled for x86_64: ```bash mkdir -p /tmp/qemu-x86-sm501-q35 cd /tmp/qemu-x86-sm501-q35 /home/chan/src/qemu-upstream/configure \ --target-list=x86_64-softmmu \ --disable-werror \ --with-devices-x86_64=sm501 \ -Ddocs=disabled \ -Dgtk=disabled \ -Dsdl=disabled ninja -C /tmp/qemu-x86-sm501-q35 qemu-system-x86_64 ``` Confirm the PCI device is present: ```bash /tmp/qemu-x86-sm501-q35/qemu-system-x86_64 -device help | grep sm501 ``` Run the Linux guest-only proof: ```bash rm -f /tmp/sm501_rce sudo -E bash -lc ' cd /mnt/c/Users/Heechan/OneDrive/문서/pwn-cve-research OUT=out/qemu-sm501-q35-linux-guest/kvm-final-guest-only-rce-2026-05-11.log \ ATTEMPTS=50 \ TIMEOUT_SECONDS=45 \ SM501_VRAM_SIZE=2097152 \ EXTRA_QEMU_ARGS="-accel kvm" \ QEMU_BIN=/tmp/qemu-x86-sm501-q35/qemu-system-x86_64 \ ./repro/qemu_sm501_linux_guest/run_q35_linux_guest_rce.sh ' ``` I used `sudo`only because my local user was not in the `kvm`group and could not open `/dev/kvm`. This makes the marker show `uid=0(root)`, but the important security point is that the guest-controlled path executes code in the QEMU process with KVM enabled. The script: 1.builds a static guest binary from `repro/qemu_sm501_linux_guest/sm501_q35_linux_guest_rce.c`; 2.creates a small initramfs; 3.boots QEMU with: ```text -M q35 -accel kvm -kernel vmlinuz-5.15.0-174-generic -initrd initramfs.cpio.gz -append "console=ttyS0 earlyprintk=serial init=/init panic=-1 quiet" -device sm501,vram-size=2097152,x-pixman=7,addr=03.0 ``` Inside the guest, the binary: 1.finds the SM501 PCI device under `/sys/bus/pci/devices`; 2.maps `resource0`and `resource1`; 3.writes `SM501_DRAM_CONTROL = 0x00008000`to select the 64 MiB emulated size; 4.uses SM501 BitBlt as a relative host OOB read primitive; 5.locates libc and libpixman through guest-visible OOB reads; 6.uses SM501 2D write/copy operations to overwrite libpixman's implementation pointer; 7.triggers `pixman_fill()`through the SM501 Rectangle Fill path. The attempts loop is used only to handle host ASLR/layout variance. ## Observed Result Saved local KVM-enabled log: ```text out/qemu-sm501-q35-linux-guest/kvm-final-guest-only-rce-2026-05-11.log ``` Relevant output: ```text ATTEMPT 1 guest init started SM501_BDF=0000:00:03.0 candidate 0x03000000 -> 7f 45 4c 46 selected_libc_rel=0x03000000 libc_candidate_dynamic=0x00219bc0 size=0x000001d0 derived_libc_abs=0x... link_map l_addr=0x... name=/lib/x86_64-linux-gnu/libpixman-1.so.0 libc_rel=0x03000000 pixman_rel=0x03ac2000 pixman_global_rel=0x03b6c140 triggered guest exploit exited rc=0 RC 0 MARKER_FOUND uid=0(root) gid=0(root) groups=0(root),999(docker) ``` The `uid=...`line is written by the QEMU host process executing the controlled `system("id>/tmp/sm501_rce;exit 1")`command. ## Impact The underlying issue is guest-controlled host out-of-bounds read/write in a QEMU device model. In my local q35 PCI lab, the primitives are sufficient to execute a command in the QEMU host process from guest code. Accurate impact wording: ```text guest-triggerable host OOB read/write and command execution in the QEMU process for KVM-enabled x86_64 q35 VMs configured with PCI sm501 and a smaller-than-64MiB vram-size. ``` I am not claiming a cloud escape or impact against deployments that do not expose SM501 to the guest. ## Suggested Fix Direction Do not use a guest-mutable emulated DRAM-size register as the host memory safety bound. Possible fixes: -keep an immutable `allocated_local_mem_size`and use it for all host pointer bounds checks; -reject `SM501_DRAM_CONTROL`writes that would change `local_mem_size_index` after initialization; -reject any runtime size change that would make `get_local_mem_size(s)`exceed the allocated RAMBlock size; -validate all 2D source/destination spans against the actual allocated RAMBlock size, not only the emulated register state. ## Files to Attach ```text reports/qemu-sm501-q35-linux-guest-rce-2026-05-10.md repro/qemu_sm501_linux_guest/sm501_q35_linux_guest_rce.c repro/qemu_sm501_linux_guest/run_q35_linux_guest_rce.sh out/qemu-sm501-q35-linux-guest/kvm-final-guest-only-rce-2026-05-11.log ``` ## Acknowledgement Please acknowledge: ```text Heechan Kang ``` [qemu-sm501-q35-kvm-guest-rce-package-2026-05-11.zip](/uploads/e2bb0411f3454929cf9c8fc29bf81ab2/qemu-sm501-q35-kvm-guest-rce-package-2026-05-11.zip)