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: `<CAJUmCq7H24DcsnZRmSLT_3vhbCUwd5xne8UneLFZBm2vZzGYLA@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 plant malformed uefi policy state that later causes a heap out-of-bounds read in the destination QEMU process during a subsequent variable update. 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 LOCK_ON_VAR_STATE policy handling after migration Affected version tested: qemu-11.0.0-rc4 Impact summary: A crafted migration stream can leave behind malformed policy state that survives post-load and is triggered later when a normal SET_VARIABLE request reaches policy checking. In my testing this is reproducible as an ASan-detected heap-buffer-overflow read in print_policy_entry(). Root cause summary: The migration restore path for uefi policy state does not apply the same layout validation that the normal runtime registration path applies to LOCK_ON_VAR_STATE entries. This allows a migration stream to: 1. restore a malformed policy entry whose name layout is inconsistent, 2. pass through post-load handling without being rejected, and 3. trigger an out-of-bounds read later when policy checking prints or inspects the policy during a variable update. In particular, print_policy_entry() dereferences a name pointer derived from pe->offset_to_name and then walks it as a uint16_t string without validating that the derived address remains inside the allocated policy entry. Code locations involved: - hw/uefi/var-service-policy.c: uefi_var_policy_post_load() - hw/uefi/var-service-policy.c: calc_policy() - hw/uefi/var-service-policy.c: print_policy_entry() - hw/uefi/var-service-vars.c: uefi_vars_policy_check() Reproducer: I attached a minimal incoming migration sample and a small trigger script. The reproducer first loads a crafted migration stream to seed malformed policy state, and then performs a minimal SET_VARIABLE request that reaches the policy check path. Observed result: AddressSanitizer reports a heap-buffer-overflow read in print_policy_entry(), reached from uefi_vars_policy_check() during a subsequent variable update. Example ASan symptom: ERROR: AddressSanitizer: heap-buffer-overflow in print_policy_entry(...) in uefi_vars_policy_check(...) in uefi_vars_mm_set_variable(...) Attack scenario: A malicious or compromised migration source can deliver crafted state to a destination QEMU process that is accepting incoming migration. The malformed policy state is then activated later by an otherwise ordinary variable update. Disclosure status: This issue is not public to the best of my knowledge. Suggested fix direction: The migration restore path should perform the same strict layout validation as the ordinary runtime path for LOCK_ON_VAR_STATE entries, and helper functions such as print_policy_entry() should not walk derived name pointers without bounds checks. Attachments: - repro.sh - uefi_var_policy_lock_trace_oob_endofdxe.mig - migration_vmstate_uefi_set_variable_qtest.py - repro.log - repro_client.log - repro_server.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-0004.zip](/uploads/4dfd764c7ca3fa04f615ba64dae12f8d/MIGRATION_VMSTATE-0004.zip)