hw/9pfs/xen: drain in-flight PDUs before xen-9p disconnect
The xen-9p disconnect path has two issues: 1. It frees the Xen9pfsRing structures while in-flight PDUs may still reference them via pdu->tag to index rings[]. This causes a UAF in xen_9pfs_push_and_notify() when worker threads resume after completing filesystem operations. 2. It never calls v9fs_device_unrealize_common(), which means server state (struct LocalData, mountfd, FIDs) is never cleaned up on disconnect, causing a resource leak on every guest-initiated disconnect. Fix both by draining in-flight PDUs via v9fs_reset() before tearing down rings, and calling v9fs_device_unrealize_common() to clean up server state. Additionally, explicit calls of xen_9pfs_disconnect() in the error paths of xen_9pfs_pdu_vmarshal() and xen_9pfs_pdu_vunmarshal() must be deferred (via aio_bh_schedule_oneshot()), because xen_9pfs_pdu_v(un)marshal() are running within a coroutine context which makes them unsafe [1] for calling v9fs_reset() directly, as the latter e.g. has a loop like: while (!QLIST_EMPTY(&s->active_list)) { aio_poll(qemu_get_aio_context(), true); } which would a) never terminate (as the coroutine is on the active_list) and b) aio_poll() is marked as no_coroutine_fn. [1] https://lore.kernel.org/qemu-devel/3351181.5fSG56mABF@weasel/ And finally, add an idempotent guard to xen_9pfs_disconnect() for the v9fs_reset(s) and v9fs_device_unrealize_common(s) calls specifically [2], just to be sure. [2] https://lore.kernel.org/qemu-devel/alpine.DEB.2.22.394.2607221815520.5295@ubuntu-linux-20-04-desktop/ Fixes: b37eeb0201 ("xen/9pfs: introduce Xen 9pfs backend") Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/qemu-devel/82bc736158e827e05d4b55da27c39d42e2062e96.1784809978.git.qemu_oss@crudebyte.com Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>