Hi Stefano,
chance that you might be looking at this v2 Xen patch soon? If not, just let
me know, then I'll send out a PR with other fixes piled up on my side in the
meantime, as QEMU release window narrows.
/Christian
On Saturday, 18 July 2026 18:50:06 CEST Christian Schoenebeck wrote:
> 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(),
> just for the case.
>
> Fixes: b37eeb0201 ("xen/9pfs: introduce Xen 9pfs backend")
> Signed-off-by: Christian Schoenebeck <[email protected]>
> ---
> hw/9pfs/xen-9p-backend.c | 19 +++++++++++++++++--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
> index 24c90d97ec..edb65a7afc 100644
> --- a/hw/9pfs/xen-9p-backend.c
> +++ b/hw/9pfs/xen-9p-backend.c
> @@ -68,6 +68,11 @@ typedef struct Xen9pfsDev {
>
> static void xen_9pfs_disconnect(struct XenLegacyDevice *xendev);
>
> +static void xen_9pfs_disconnect_bh(void *opaque)
> +{
> + xen_9pfs_disconnect(opaque);
> +}
> +
> static void xen_9pfs_in_sg(Xen9pfsRing *ring,
> struct iovec *in_sg,
> int *num,
> @@ -150,7 +155,8 @@ static ssize_t xen_9pfs_pdu_vmarshal(V9fsPDU *pdu,
> "Failed to encode VirtFS reply type %d\n",
> pdu->id + 1);
> xen_be_set_state(&xen_9pfs->xendev, XenbusStateClosing);
> - xen_9pfs_disconnect(&xen_9pfs->xendev);
> + aio_bh_schedule_oneshot(qemu_get_aio_context(),
> + xen_9pfs_disconnect_bh, &xen_9pfs->xendev);
> }
> return ret;
> }
> @@ -173,7 +179,8 @@ static ssize_t xen_9pfs_pdu_vunmarshal(V9fsPDU *pdu,
> xen_pv_printf(&xen_9pfs->xendev, 0,
> "Failed to decode VirtFS request type %d\n",
> pdu->id); xen_be_set_state(&xen_9pfs->xendev, XenbusStateClosing);
> - xen_9pfs_disconnect(&xen_9pfs->xendev);
> + aio_bh_schedule_oneshot(qemu_get_aio_context(),
> + xen_9pfs_disconnect_bh, &xen_9pfs->xendev);
> }
> return ret;
> }
> @@ -368,10 +375,18 @@ static void xen_9pfs_evtchn_event(void *opaque)
> static void xen_9pfs_disconnect(struct XenLegacyDevice *xendev)
> {
> Xen9pfsDev *xen_9pdev = container_of(xendev, Xen9pfsDev, xendev);
> + V9fsState *s = &xen_9pdev->state;
> int i;
>
> + if (!xen_9pdev->rings) {
> + return;
> + }
> +
> trace_xen_9pfs_disconnect(xendev->name);
>
> + v9fs_reset(s);
> + v9fs_device_unrealize_common(s);
> +
> for (i = 0; i < xen_9pdev->num_rings; i++) {
> if (xen_9pdev->rings[i].evtchndev != NULL) {
>
> qemu_set_fd_handler(qemu_xen_evtchn_fd(xen_9pdev->rings[i].evtchndev),
