Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
softmmu/ioport.c: make MemoryRegionPortioList owner of portio_list Me…
…moryRegions Currently when portio_list MemoryRegions are freed using portio_list_destroy() the RCU thread segfaults generating a backtrace similar to that below: #0 0x5555599a34b6 in phys_section_destroy ../softmmu/physmem.c:996 #1 0x5555599a37a3 in phys_sections_free ../softmmu/physmem.c:1011 qemu#2 0x5555599b24aa in address_space_dispatch_free ../softmmu/physmem.c:2430 qemu#3 0x55555996a283 in flatview_destroy ../softmmu/memory.c:292 qemu#4 0x55555a2cb9fb in call_rcu_thread ../util/rcu.c:284 qemu#5 0x55555a29b71d in qemu_thread_start ../util/qemu-thread-posix.c:541 qemu#6 0x7ffff4a0cea6 in start_thread nptl/pthread_create.c:477 qemu#7 0x7ffff492ca2e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0xfca2e) The problem here is that portio_list_destroy() unparents the portio_list MemoryRegions causing them to be freed immediately, however the flatview still has a reference to the MemoryRegion and so causes a use-after-free segfault when the RCU thread next updates the flatview. Solve the lifetime issue by making MemoryRegionPortioList the owner of the portio_list MemoryRegions, and then reparenting them to the portio_list owner. This ensures that they can be accessed as QOM children via the portio_list owner, yet the MemoryRegionPortioList owns the refcount. Update portio_list_destroy() to unparent the MemoryRegion from the portio_list owner (while keeping mrpio->mr live until finalization of the MemoryRegionPortioList), so that the portio_list MemoryRegions remain allocated until flatview_destroy() removes the final refcount upon the next flatview update. Signed-off-by: Mark Cave-Ayland <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
- Loading branch information