Both the arm and i386 hvf accelerators have the same bug in their
dirty-page logging path: the address fed to memory_region_set_dirty()
is computed as "<ipa,gpa>_page + xlat", but memory_region_set_dirty()
expects an offset relative to the start of the resolved MemoryRegion.
address_space_translate() already returns that offset in xlat, while
ipa_page / gpa_page is the guest-physical (system address space)
address.
Adding the two together produces a bogus offset that for any non-
trivial RAM size walks well past the end of the MemoryRegion's dirty
bitmap. With dirty logging active (e.g. live migration on a guest
with several GB of RAM), this triggers an out-of-bounds atomic write
inside bitmap_set_atomic() and crashes the source QEMU as soon as the
guest writes to RAM:
Thread .. 'CPU N/HVF', stop reason = EXC_BAD_ACCESS ...
bitmap_set_atomic at bitmap.c:213
physical_memory_set_dirty_range at physmem.c:1038
memory_region_set_dirty at memory.c:2191
hvf_handle_exception at hvf.c
Fix it by passing only the MR-relative offset xlat. ipa_page /
gpa_page is still the right argument to hvf_unprotect_dirty_range(),
which works on the guest-physical address space.
Signed-off-by: Scott J. Goldman <scottjgo@gmail.com>
Link: https://lore.kernel.org/r/20260427232116.50586-2-scottjgo@gmail.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
assert(!mr->readonly);
if (memory_region_get_dirty_log_mask(mr)) {
- memory_region_set_dirty(mr, ipa_page + xlat, page_size);
+ memory_region_set_dirty(mr, xlat, page_size);
hvf_unprotect_dirty_range(ipa_page, page_size);
}
if (write && memory_region_get_dirty_log_mask(mr)) {
uintptr_t page_size = qemu_real_host_page_size();
- memory_region_set_dirty(mr, gpa_page + xlat, page_size);
+ memory_region_set_dirty(mr, xlat, page_size);
hvf_unprotect_dirty_range(gpa_page, page_size);
}