Imported by the "Security Issuer Importer" bot, on behalf of the original reporter who disclosed via qemu-security list: * From: `김승중 <seungjung0711@gmail.com>` * Date: `21 Mar, 2026` * Message ID: `<CAHntc+PT1hH2k9_M2gX+AnDbkLzichj_mLOdEUFMicudXFB19A@mail.gmail.com>` **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. ---- vhost inflight migration buffer size truncation causes heap buffer overflow on destination host Automated Tool Disclosure An AI/LLM tool was used during initial code review to flag a potential type mismatch in the vhost inflight migration path. The reporter subsequently performed manual human triage: - Traced the full code path across 5 source files - Confirmed the int32_t truncation of a uint64_t field - Verified the implicit int-to-size_t sign extension - Validated that no bounds check exists between vmstate_size() and qemu_get_buffer() - Verified against VMS_VBUFFER documentation which explicitly specifies int32_t (include/migration/vmstate.h:106) - Confirmed the follow-up fix commit 72f663f575 only addressed the error check, *NOT* the size truncation The finding was validated through manual source code analysis prior to this submission. ## QEMU Version Upstream QEMU master branch (tested at HEAD: 8e711856d7). Relevant commits: Commit Description Note f6fdd8b2bd vmstate: introduce VMSTATE_VBUFFER_UINT64 Introduced macro with uint64_t size_offset, incompatible with vmstate_size()'s int32_t read 3a80ff0721 vhost: add vmstate for inflight region with inner buffer Used the broken macro for vhost inflight migration 72f663f575 vhost: fix vhost_inflight_buffer_pre_load Fixed only error check (*errp → !addr) and return type. *Did NOT address the size truncation* Host ## Guest Architecture - *Host*: x86_64, 64-bit, little-endian - *Guest*: any (architecture-independent; the bug is in host-side migration deserialization) ## Summary vmstate_size() (migration/vmstate.c:113) reads all VMS_VBUFFER size fields as int32_t. This is consistent with the VMS_VBUFFER documentation ( include/migration/vmstate.h:106) which explicitly specifies: *"Use the int32_t at opaque + VMStateField.size_offset"* However, commit f6fdd8b2bd introduced VMSTATE_VBUFFER_UINT64, which sets size_offset to a uint64_t field. This creates a type mismatch: vmstate_size() reads 4 bytes as int32_t from a field that is actually 8 bytes wide. Commit 3a80ff0721 then used this macro for vhost inflight migration. When a migration stream carries inflight->size with bit 31 set in the low 32 bits (e.g. >= 0x80000000), the int32_t read yields a negative value. This negative int is implicitly converted to a huge size_t (~18 EB) when passed to get_buffer(), causing qemu_get_buffer() to write far beyond the allocated inflight buffer on the destination host. ## Security Relevance Addressing the triage criteria from the QEMU security process: *Q: Is there a feasible way for a malicious party to exploit this and cause real damage?* A: Yes. A compromised source host or a network-level attacker with access to the migration channel can inject a crafted inflight->size value into the migration stream. This causes a heap buffer overflow on the destination QEMU process. Per docs/system/security.rst:31, live migration ("Network protocols") is explicitly classified as untrusted. *Q: Does the flaw require access to the management interface?* A: No. The flaw is triggered by data in the migration stream itself, not through QMP/HMP commands. *Q: Is QEMU used with a hypervisor?* A: Yes. vhost-user devices (vhost-user-blk with SPDK, vhost-user-net with OVS/DPDK) are used in KVM-based production virtualization environments where live migration with inflight I/O tracking is a standard operational procedure. *Q: Is QEMU used for production services?* A: Yes. vhost-user is specifically designed for high-performance production workloads (cloud, VPS, data center virtualization). Unlike the sdhci example (commit 9201bb9) where the interface was disabled by default and only used in developer SoC emulation, vhost-user live migration is an actively used production feature on supported machine types (q35, pc, virt, etc.). ------------------------------ Configuration / Settings Required The issue is triggered when *all* of these conditions are met: 1. A vhost-user device with inflight I/O tracking is configured (e.g. vhost-user-blk-pci, vhost-user-scsi-pci) 2. Live migration is performed to a destination host 3. The migration stream contains the vhost-inflight-region subsection with a crafted size value (bit 31 set in low 32 bits) ## QEMU Command Line Destination host example (receiving migration with vhost-user-blk): ``` qemu-system-x86_64 \ -machine q35,accel=kvm \ -m 4G \ -chardev socket,id=char0,path=/tmp/vhost.sock \ -device vhost-user-blk-pci,chardev=char0 \ -incoming tcp:0:4444 ``` The destination loads the vhost-inflight-region vmstate from the incoming migration stream, triggering the vulnerable code path. ## Reproducer Steps No runtime reproducer is available at this time. However, the vulnerability is a *deterministic type safety bug* with no timing or race condition dependencies: 1. Start a destination QEMU with a vhost-user device and -incoming, as shown above 2. From the source (or using a crafted migration stream tool), send a migration stream where the vhost-inflight-region subsection contains: - VMSTATE_UINT64(size) = 0x80000000 (or any value with bit 31 set in the low 32 bits) 3. The destination QEMU process will crash or corrupt memory when loading the VBUFFER field ## *Conceptual code-level trace:* ``` uint64_t size = 0x80000000; // from migration stream // pre_load allocates: qemu_memfd_alloc(..., 0x80000000, ...) // → 2 GB buffer allocated (size_t parameter, uses full uint64) // vmstate_size() at migration/vmstate.c:113: int32_t truncated = *(int32_t *)&size; // → -2147483648 // vmstate_load_state passes int to get callback (size_t param): size_t read_size = (size_t)(int)truncated; // → 0xFFFFFFFF80000000 // qemu_get_buffer memcpy loop with ~18 EB into 2 GB buffer → OOB ``` ## Affected Code (with line references) 1. include/migration/vmstate.h:106-109 DESIGN SPECIFICATION ``` /* Use the int32_t at opaque + * VMStateField.size_offset ... */ VMS_VBUFFER = 0x100, ``` The VMS_VBUFFER flag documentation explicitly specifies int32_t as the expected type for the size field. 2. include/migration/vmstate.h:719-727 — INCOMPATIBLE MACRO ``` VMSTATE_VBUFFER_UINT64 sets: .size_offset = vmstate_offset_value(_state, _field_size, uint64_t) ``` This points to a uint64_t field, violating the int32_t contract of VMS_VBUFFER. Introduced in commit f6fdd8b2bd. 3. hw/virtio/vhost.c:1961-1973 vmstate_vhost_inflight_region defines: ``` VMSTATE_UINT64(size, struct vhost_inflight) ``` Loading this field from the stream populates inflight->size (uint64_t, include/hw/virtio/vhost.h:19) with an attacker-controlled value. 4. hw/virtio/vhost.c:1919-1936 vhost_inflight_buffer_pre_load() allocates a memfd buffer via qemu_memfd_alloc(name, size_t size, ...) using the full uint64_t inflight->size. No size validation is performed. 5. hw/virtio/vhost.c:1938-1945 ``` VMSTATE_VBUFFER_UINT64(addr, struct vhost_inflight, 0, NULL, size) ``` Triggers field loading with the broken macro. 6. migration/vmstate.c:108-120 — ROOT CAUSE ``` static int vmstate_size(void *opaque, const VMStateField *field) { int size = field->size; if (field->flags & VMS_VBUFFER) { size = *(int32_t *)(opaque + field->size_offset); } return size; } ``` Reads the uint64_t field through an int32_t pointer. On little-endian x86_64, this reads the low 32 bits with sign interpretation. 7. migration/vmstate.c:180,215 ``` int size = vmstate_size(opaque, field); // negative int ... ret = inner_field->info->get(f, curr_elem, size, inner_field); ``` The get callback signature (include/migration/vmstate.h:44): ``` int (*get)(QEMUFile *f, void *pv, size_t size, ...) ``` Negative int is implicitly converted to huge size_t. 8. migration/vmstate-types.c:486-491 ``` static int get_buffer(QEMUFile *f, void *pv, size_t size, ...) { uint8_t *v = pv; qemu_get_buffer(f, v, size); return 0; } ``` No bounds check. Passes corrupted size_t to qemu_get_buffer. 9. migration/qemu-file.c:706-724 qemu_get_buffer() performs memcpy in a loop for the full requested size, writing past the end of the allocated buffer. ## Stack Traces Not available (no runtime reproducer). This is a deterministic type truncation bug; an ASan-enabled QEMU build receiving inflight->size >= 0x80000000 in the migration stream should produce a heap-buffer-overflow at the qemu_get_buffer() → memcpy() call site (migration/qemu-file.c:719). ## Impact - *Heap buffer overflow* on the destination QEMU host process - *Denial of service* (crash) is certain - *Potential for code execution* in the QEMU host process context depending on heap layout ## Suggested Fix *Immediate mitigation* — validate inflight->size before allocation and VBUFFER load: ``` --- a/hw/virtio/vhost.c +++ b/hw/virtio/vhost.c @@ -1919,6 +1919,12 @@ static bool vhost_inflight_buffer_pre_load(void *opaque, Error **errp) { struct vhost_inflight *inflight = opaque; + if (inflight->size > INT32_MAX) { + error_setg(errp, "inflight size exceeds migration limit: %" PRIu64, + inflight->size); + return false; + } + int fd = -1; void *addr = qemu_memfd_alloc("vhost-inflight", inflight->size, F_SEAL_GROW | F_SEAL_SHRINK | F_SEAL_SEAL, ``` ## *Root cause fix* — vmstate_size() should also be updated to handle uint64_t size offsets when used with VMSTATE_VBUFFER_UINT64. This could be done by introducing a new VMS flag (e.g. VMS_VBUFFER_64) or by widening the size_offset read to match the actual field type. VMSTATE_VBUFFER_UINT64 currently has only this one caller, so the pre_load guard above is sufficient as an immediate fix. ## Additional Notes - On *big-endian* hosts, vmstate_size() would read the upper 32 bits of the uint64_t instead of the lower 32 bits. For sizes < 4 GB, this yields 0, causing silent data loss (no buffer data transferred) rather than an overflow. This is a functionality bug on big-endian, a security bug on little-endian. - VMSTATE_VBUFFER_UINT32 (used in ~15 other devices) has a similar theoretical issue: uint32_t values >= 0x80000000 would be read as negative int32_t. In practice, those devices have small compile-time-bounded sizes, so the risk is lower. The vhost inflight case is uniquely dangerous because both the size and buffer data are attacker-controlled via the migration stream. ## Acknowledgment Please credit: *Seungjung Kim, Kyonggi University* *Full report attached as security-report.md* [security-report.md](/uploads/2382667c61593c6b3bbf83e379ed45f8/security-report.md)