When attempting to use portio_list_destroy() to remove a portio_list then the
QEMU process segfaults with the backtrace below:
#0 0x5555599a34b6 in phys_section_destroy ../softmmu/physmem.c:996
#1 0x5555599a37a3 in phys_sections_free ../softmmu/physmem.c:1011
#2 0x5555599b24aa in address_space_dispatch_free ../softmmu/physmem.c:2430
#3 0x55555996a283 in flatview_destroy ../softmmu/memory.c:292
#4 0x55555a2cb9fb in call_rcu_thread ../util/rcu.c:284
#5 0x55555a29b71d in qemu_thread_start ../util/qemu-thread-posix.c:541
#6 0x7ffff4a0cea6 in start_thread nptl/pthread_create.c:477
#7 0x7ffff492ca2e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0xfca2e)
The problem 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 which causes a use-after-free segfault when the RCU thread next
updates
the flatview.
This series resolves the issue by QOMifying the MemoryRegionPortioList, and
setting
that as the MemoryRegion owner instead of the portio_list owner. This allows the
MemoryRegionPortioList to hold the refcount for its MemoryRegion and so manually
finalize it when flatview_destroy() removes its final refcount.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
Mark Cave-Ayland (3):
softmmu/ioport.c: allocate MemoryRegionPortioList ports on the heap
softmmu/ioport.c: QOMify MemoryRegionPortioList
softmmu/ioport.c: make MemoryRegionPortioList owner of portio_list
MemoryRegions
softmmu/ioport.c | 62 ++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 55 insertions(+), 7 deletions(-)
--
2.30.2
