## Executive Summary Mallory supplies a crafted VHDX disk image to an operator who legitimately attaches user-supplied images to a KVM-accelerated QEMU virtual machine. The image advertises a virtual size chosen so that QEMU truncates the 64-bit payload-block count into 32 bits while opening the image. A later ordinary guest read within that advertised virtual disk indexes one entry beyond the heap allocation holding the Block Allocation Table (BAT). This is not session theft, a monitor-console attack, or a malformed migration stream: the starting input is an untrusted disk image, which QEMU's virtualization security policy expressly treats as untrusted. I reviewed QEMU 11.1.50 at source revision `1df256f5968e9f7c3c4533a1383b071c044a36d6`, inspected the complete source history and release tags, generated the image, and reproduced the out-of-bounds read through `qemu-io`. I also inspected the preserved run from the same binary in which a Linux guest on `q35` with KVM reached the identical sink. AddressSanitizer reported an eight-byte heap-buffer-overflow in `vhdx_block_translate()` and terminated QEMU. A clean 64 MiB VHDX control completed the same class of read normally. I did not demonstrate disclosure of host memory, host code execution, or modification of host resources. The reachable VHDX read path entered QEMU in commit `059e2fbbca48` and is present in the QEMU 1.5.0 release tag, the earliest affected release I verified. Source history and inspected release snapshots retain the 32-bit count and unchecked BAT dereference through the assessed QEMU 11.1.50 development snapshot. I found no fixed release in the inspected history. Classification: CWE-190 (Integer Overflow or Wraparound), CWE-125 (Out-of-bounds Read); CVSS v3.1 **5.5 Medium** (`CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H`). ## Background ### Host environment - **Operating system:** QEMU ran inside a Debian 12 container on an Ubuntu 24.04.4 LTS host. - **OS/kernel version:** `Linux 6.8.0-134-generic #134-Ubuntu SMP PREEMPT_DYNAMIC Fri Jun 26 18:43:11 UTC 2026 x86_64 GNU/Linux` (hostname omitted). - **Architecture:** x86_64. - **QEMU flavor:** `qemu-system-x86_64`, `qemu-img`, and `qemu-io`. - **QEMU version:** all three binaries reported QEMU 11.1.50. - **Source revision:** upstream QEMU `1df256f5968e9f7c3c4533a1383b071c044a36d6` was built and runtime-tested. Fetched master `d43c2d5f89db70359a7b3a7e2ad7098fcc0165ef` still contains the affected 32-bit calculation and unchecked BAT access, but was source-inspected only and was not runtime-tested. - **QEMU command line:** the smallest complete trigger after fixture generation is: ```sh qemu-io -r -f vhdx -c 'read 1097372532736 4096' poc/artifacts/truncated-bat.vhdx ``` The following `qemu-system-x86_64` command matches the validated KVM topology: ```sh ASAN_OPTIONS=detect_leaks=0:abort_on_error=1:symbolize=1 \ qemu-system-x86_64 \ -M q35 -accel kvm -cpu host -m 512M -nodefaults \ -display none -monitor none -serial stdio \ -kernel ./vmlinuz \ -initrd ./initramfs-revalidation.cpio.gz \ -append 'console=ttyS0 loglevel=3 rdinit=/init panic=-1 reval=vhdx-oob' \ -drive 'file=poc/artifacts/truncated-bat.vhdx,if=virtio,format=vhdx,readonly=on' ``` The validation initramfs dispatches `reval=vhdx-oob` to the raw `dd` read shown in the PoC steps. The kernel and initramfs are ordinary validation assets, not required for the smaller `qemu-io` reproducer. ### Emulated/Virtualized environment - **Operating system:** minimal BusyBox Linux initramfs. - **OS/kernel version:** the guest `uname -a` output was not captured; no guest kernel-version claim is made. - **Architecture:** x86_64. - **Machine/accelerator:** `q35` with KVM and `-cpu host`. - **Device/topology:** the malformed VHDX was attached as a virtio block device and appeared as `/dev/vda` in the validation guest. QEMU's VHDX block driver reads the image's `Virtual Disk Size` metadata as a 64-bit value. It uses that value and the VHDX payload block size to derive how many BAT entries the image needs. The BAT maps virtual payload blocks to offsets in the VHDX file. Before any guest I/O, QEMU loads the BAT region into a host heap allocation. The tested topology was QEMU 11.1.50 built with ASan/UBSan, an x86-64 `q35` machine, KVM acceleration, and a Linux guest using the VHDX as a virtio block disk. The crafted image uses an 8 MiB payload block size, 512-byte logical sectors, and a 1 MiB BAT region containing room for 131,072 eight-byte entries. The operator must attach Mallory's image; a guest read at the affected logical offset then reaches the faulty lookup. No QMP access or guest kernel modification is required to make the vulnerable block driver process the image, although raw block access was used in the guest to select the exact sector during validation. Expected behavior is to reject a VHDX whose declared virtual disk size exceeds QEMU's supported VHDX maximum, whose calculated BAT entry count cannot be represented, or whose requested BAT index is outside the loaded BAT. QEMU already defines `VHDX_MAX_IMAGE_SIZE` as 64 TiB in `block/vhdx.h`, but the assessed open path applies that limit when creating an image and not when parsing an existing image. ## Vulnerability Details ### Description of problem Mallory changes the little-endian 64-bit `Virtual Disk Size` metadata at VHDX file offset `0x310008` to `0x8000ff80000000`. `vhdx_parse_metadata()` in `block/vhdx.c` reads this value directly into the 64-bit `s->virtual_disk_size`. After metadata parsing, `vhdx_open()` advertises the corresponding sectors and calls the BAT sizing helper: ```c /* block/vhdx.c, vhdx_open(), QEMU 11.1.50 */ bs->total_sectors = s->virtual_disk_size >> s->logical_sector_size_bits; vhdx_calc_bat_entries(s); ``` The helper stores the rounded 64-bit division result in a 32-bit variable: ```c /* block/vhdx.c, vhdx_calc_bat_entries(), QEMU 11.1.50 */ static void vhdx_calc_bat_entries(BDRVVHDXState *s) { uint32_t data_blocks_cnt, bitmap_blocks_cnt; data_blocks_cnt = DIV_ROUND_UP(s->virtual_disk_size, s->block_size); bitmap_blocks_cnt = DIV_ROUND_UP(data_blocks_cnt, s->chunk_ratio); if (s->parent_entries) { s->bat_entries = bitmap_blocks_cnt * (s->chunk_ratio + 1); } else { s->bat_entries = data_blocks_cnt + ((data_blocks_cnt - 1) >> s->chunk_ratio_bits); } } ``` For the crafted value and 8 MiB block size, the correct payload-block count is `0x10001ff00` (4,295,098,112). Assignment to `uint32_t data_blocks_cnt` discards the high bit and produces `0x1ff00` (130,816). With a chunk ratio of 512 and no parent image, QEMU calculates only 131,071 BAT entries. The subsequent capacity check therefore accepts the 1 MiB BAT region, which physically contains 131,072 entries: ```c /* block/vhdx.c, vhdx_open(), QEMU 11.1.50 */ if (s->bat_entries > s->bat_rt.length / sizeof(VHDXBatEntry)) { ret = -EINVAL; goto fail; } s->bat = qemu_try_blockalign(bs->file->bs, s->bat_rt.length); ``` A read at byte offset `1097372532736` (`0xff80800000`, LBA 2,143,305,728 for 512-byte sectors) selects payload-block index 130,817. Accounting for the interleaved sector-bitmap entries produces BAT index 131,072. `vhdx_block_translate()` uses that index without checking it against `s->bat_entries` or the loaded BAT capacity: ```c /* block/vhdx.c, vhdx_block_translate(), QEMU 11.1.50 */ sinfo->bat_idx = sector_num >> s->sectors_per_block_bits; sinfo->bat_idx += sinfo->bat_idx >> s->chunk_ratio_bits; sinfo->file_offset = s->bat[sinfo->bat_idx] & VHDX_BAT_FILE_OFF_MASK; ``` The final statement reads eight bytes immediately beyond the 1 MiB heap allocation. The same unchecked index is used again by `vhdx_co_readv()` when it evaluates the BAT state. The reachable read logic was added by `059e2fbbca48` (`block: add read-only support to VHDX image format`) in May 2013. QEMU 1.5.0 contains the 32-bit payload-block counter and unchecked `s->bat[sinfo->bat_idx]` lookup. I also inspected representative tags through QEMU 11.0.0 and the assessed 11.1.50 snapshot; the vulnerable data-width and sink remain. No fix or backport was present in the available history. ## Exploitability Analysis The narrow established primitive is an eight-byte host heap read one BAT entry beyond an allocation controlled in size by image metadata. With ASan, this reliably aborts the QEMU process at `block/vhdx.c:1152`, crossing from an untrusted user-supplied disk image into the availability of the host QEMU process. Without ASan, the read consumes adjacent heap contents as a BAT entry. That may result in a zero/unmapped block decision, an invalid file offset, or a fault depending on allocator layout and adjacent data; this report does not claim a deterministic non-instrumented crash. The out-of-bounds value is masked and treated as an offset/state value for the same attacker-supplied image. The PoC did not return the adjacent host bytes directly to the guest, demonstrate disclosure of host data, corrupt host memory, or obtain code execution. Those stronger outcomes should not be inferred from the sanitizer finding. The KVM positive test booted a Linux guest on `q35`, issued the eight-sector read at the crafted offset, and produced: ```text VHDX_OOB_READ_BEGIN ERROR: AddressSanitizer: heap-buffer-overflow READ of size 8 #0 vhdx_block_translate ../block/vhdx.c:1152 #1 vhdx_co_readv ../block/vhdx.c:1203 [run-specific address omitted] is located 0 bytes to the right of 1048576-byte region ``` This establishes that the fault is reachable through a supported virtualization configuration, not only through a block-driver unit harness. The clean-image control booted under the same KVM/q35 topology and completed an ordinary eight-sector read before powering off normally: ```text VHDX_CONTROL_READ_BEGIN 8+0 records in 8+0 records out VHDX_CONTROL_READ_END rc=0 ``` I also ran the smaller `qemu-io` reproducer against the generated images. The malformed image reached the same source line and allocation boundary, while a 4 KiB read from the clean image completed successfully. The common ASan `makecontext/swapcontext` warning appeared independently of the trigger and is not the finding. ## Proof of Concept Attachment : [vhdx-bat-oob-poc.zip](/uploads/8d4bdba7b4a7e60d6d73a3553d9506bd/vhdx-bat-oob-poc.zip) ### Steps to reproduce `make_vhdx_fixture.py` generates a clean 64 MiB VHDX and changes only its virtual-size metadata for the malformed copy. `run.sh` performs the clean read and then the malformed read with `qemu-io`, while `observed-output.txt` records the concise output from the assessed build. Run these commands from this report's directory with an ASan-enabled QEMU build whose `qemu-img` and `qemu-io` binaries are on `PATH`: 1. Enter the PoC directory and generate the clean and malformed images: ```sh cd poc python3 ./make_vhdx_fixture.py ./artifacts ``` 2. Run the ordinary control. It should complete a 4 KiB read: ```sh qemu-io -r -f vhdx -c 'read 0 4096' artifacts/clean-64m.vhdx ``` 3. Run the malformed input. On the assessed ASan build, this aborts with an eight-byte heap-buffer-overflow at `block/vhdx.c:1152`: ```sh qemu-io -r -f vhdx -c 'read 1097372532736 4096' artifacts/truncated-bat.vhdx ``` 4. As a convenience, repeat steps 1 through 3 in a fresh output directory with the checked runner: ```sh ./run.sh artifacts-second-run ``` `run.sh` first creates `artifacts/clean-64m.vhdx` and `artifacts/truncated-bat.vhdx`. It then performs a 4 KiB read at offset zero from the clean image, followed by the triggering 4 KiB read at offset `1097372532736` from the malformed image. The first command should report `read 4096/4096 bytes at offset 0`. The second should terminate the instrumented process with an ASan heap-buffer-overflow at `vhdx_block_translate()`. To exercise the same route through a VM, attach `artifacts/truncated-bat.vhdx` read-only as a virtio block disk to a KVM-accelerated `q35` guest. From the guest, issue the raw read below, replacing `/dev/vda` only if the attached test disk has a different guest device name: ```sh dd if=/dev/vda of=/dev/null bs=512 skip=2143305728 count=8 ``` Use only a disposable VM and an instrumented QEMU process. The positive test intentionally aborts QEMU and therefore terminates the VM. The provided commands open the images read-only and do not modify an existing disk, but the generator creates new files under `poc/artifacts/`; use a fresh directory or remove previous generated fixtures deliberately before rerunning. ### Additional information - **Positive runtime record:** ASan reported `READ of size 8` in `vhdx_block_translate()` at `block/vhdx.c:1152`, exactly zero bytes after a 1,048,576-byte allocation. - **Negative control:** the equivalent 4 KiB read from the generated clean 64 MiB VHDX completed. The KVM/q35 guest control also completed its eight-sector read and powered off normally. - **Safety:** use a disposable ASan-enabled process or VM. The positive test intentionally terminates QEMU. Both reads use read-only mode; the generator creates new fixtures and refuses to overwrite existing files. ## Remediation Reject unsupported virtual sizes while parsing an existing VHDX, before assigning `bs->total_sectors` or calculating the BAT size. The open path should enforce the same `VHDX_MAX_IMAGE_SIZE` limit already used by image creation and verify that the virtual size is a multiple of the logical sector size. BAT sizing should use 64-bit intermediates and checked conversion into `s->bat_entries`; it must fail rather than truncate. As defense in depth, `vhdx_block_translate()` should return an error when its calculated BAT index is greater than or equal to both the validated entry count and `bat_rt.length / sizeof(VHDXBatEntry)` before dereferencing `s->bat`. Its callers should propagate that error without reading the BAT a second time. This protects the sink if a future metadata inconsistency bypasses the open-time calculation. A regression test should generate the same small VHDX fixture and confirm that the crafted virtual size is rejected during open. Nearby cases should include the maximum supported 64 TiB size, one logical sector above that maximum, a non-sector-aligned virtual size, and BAT indexes at the last valid entry and one past it. The ordinary 64 MiB image must continue to open and read successfully. No shipped fix or fixed release was available to verify in the assessed history. ## Summary An untrusted VHDX can advertise `virtual_disk_size=0x8000ff80000000`, causing QEMU's 64-bit payload-block count to truncate into a 32-bit BAT count during image open. A guest read at LBA 2,143,305,728 then indexes entry 131,072 in a 131,072-entry heap allocation. QEMU 1.5.0 is the earliest affected release I verified, the flaw remains in the assessed QEMU 11.1.50 snapshot, and no fixed release was found. The demonstrated security effect is an eight-byte heap out-of-bounds read and ASan-enforced QEMU process abort under a supported KVM/q35 configuration; host-data disclosure and code execution were not demonstrated. ### AI Disclosure AI-assisted tooling helped prepare this report. I have ran the PoC and verified the report myself.