A guest can trigger unplugging 9pfs server's virtio-pci device via ACPI eject. As a consequence the device is unrealized, server's internal state is freed while pending coroutines would still have access to them, causing a potential heap-use-after-free.
Overview Patches: - Patch 1: this is the core fix, that drains all PDUs (i.e. coroutines that handle individual pending requests in parallel) before freeing server state. - Patch 2: hardens security by disabling guest triggered ACPI rejects in general for 9pfs's virtio transport. - Patch 3: fixes a similar identified issue with the Xen transport, even though not triggered via ACPI, it is also prone to UAF, plus a resource leak. Independent of this series, it should be considered to globally change the default value of devices' hotpluggable property from default enabled, to default disabled. Because as this issue showed, it should be a conscious decision of developers to explicitly opt-in when knowing that their device DOES support hot-unplugging AND that it actually makes sense for the device category. As changing the default value affects a massive amount of devices in QEMU, I am still investigating this and this is of course not covered yet by this series. Christian Schoenebeck (3): hw/9pfs/virtio: drain in-flight PDUs before virtio-9p unrealize hw/9pfs/virtio: disable hotpluggable property of virtio-9p device hw/9pfs/xen: drain in-flight PDUs before xen-9p disconnect hw/9pfs/virtio-9p-device.c | 2 ++ hw/9pfs/xen-9p-backend.c | 4 ++++ 2 files changed, 6 insertions(+) -- 2.47.3
