Imported by the "Security Issuer Importer" bot, on behalf of the original reporter who disclosed via qemu-security list: * From: `boy juju <agx1657748706@gmail.com>` * Date: `18 May, 2026` * Message ID: `<CAJUmCq6qjcYtFD_usnaL-KurL08spT2ySRFeK4S5PkuUgzcGkg@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. ---- I would like to report a potential security issue in QEMU's incoming migration / vmstate deserialization path for uefi variable policy state. Automated discovery declaration: This issue was discovered with fuzzing assistance and then manually triaged and validated. I believe this issue may be security-relevant because a malicious migration source can trigger a heap out-of-bounds read in the destination QEMU process during post-load processing of migrated uefi variable policy entries. If you confirm that this falls within QEMU's security policy, please assign a CVE and handle it under coordinated disclosure. Affected area: migration / vmstate deserialization uefi-vars-x64 device state loading uefi variable policy post-load parsing Affected version tested: qemu-11.0.0-rc4 Impact summary: A crafted migration stream can cause the destination QEMU process to read beyond the end of an allocated policy entry buffer while executing calc_policy() during policy post-load. In my testing this is reproducible as an ASan-detected heap-buffer-overflow read. Root cause summary: The migration restore path allocates a policy entry buffer according to the serialized entry_size field, but later trusts an attacker-controlled offset_to_name value without reusing the stricter runtime validation that is normally applied when such policies are registered through ordinary execution paths. Specifically: 1. VMSTATE_VBUFFER_ALLOC_UINT32 allocates a small entry buffer based on entry_size. 2. During post-load, calc_policy() computes: pol->name = (void *)pol->entry + pe->offset_to_name; pol->name_size = pe->size - pe->offset_to_name; 3. A crafted offset_to_name far beyond the actual entry buffer causes subsequent UCS-2 string processing to read out of bounds. Code locations involved: - hw/uefi/var-service-policy.c: uefi_var_policy_post_load() - hw/uefi/var-service-policy.c: calc_policy() Reproducer: I attached a minimal incoming migration sample and a simple reproducer script. The destination instance is started with an incoming migration file similar to: ./qemu-system-x86_64 \ -machine q35,accel=tcg \ -display none \ -incoming "exec:cat uefi_var_policy_oob_read.mig" Observed result: AddressSanitizer reports a heap-buffer-overflow read with the faulting stack in calc_policy() during uefi_var_policy_post_load(). Example ASan symptom: ERROR: AddressSanitizer: heap-buffer-overflow in calc_policy(...) in uefi_var_policy_post_load(...) Attack scenario: A malicious or compromised migration source can send a crafted migration stream to a destination QEMU process that is accepting incoming migration and has the relevant uefi variable state enabled, causing an out-of-bounds read during state reconstruction. Disclosure status: This issue is not public to the best of my knowledge. Suggested fix direction: The migration restore path should reuse the same structural validation that is applied on normal policy registration. At minimum, offset_to_name should be rejected unless it is fully contained within the allocated entry buffer. Attachments: - repro.sh - uefi_var_policy_oob_read.mig - repro.log Please let me know if you would like me to provide: - the full ASan log, - a minimized test case in a different format, - or a proposed patch. [MIGRATION_VMSTATE-0002.zip](/uploads/7b7e014ae89d0d7e65ed6ecfcfb18fca/MIGRATION_VMSTATE-0002.zip)