On Thu, 16 Jul 2026, Christian Schoenebeck wrote:
> Hi Stefano,
> 
> do you might have a chance to look at this Xen patch?

Sorry for the delay


> /Christian
> 
> On Thursday, 9 July 2026 15:50:36 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.
> > 
> > Fixes: b37eeb0201 ("xen/9pfs: introduce Xen 9pfs backend")
> > Signed-off-by: Christian Schoenebeck <[email protected]>
> > ---
> >  hw/9pfs/xen-9p-backend.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
> > index 24c90d97ec..3b7a68779a 100644
> > --- a/hw/9pfs/xen-9p-backend.c
> > +++ b/hw/9pfs/xen-9p-backend.c
> > @@ -368,10 +368,14 @@ 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;
> > 
> >      trace_xen_9pfs_disconnect(xendev->name);
> > 
> > +    v9fs_reset(s);
> > +    v9fs_device_unrealize_common(s);

While the patch addresses a real issue, xen_9pfs_disconnect() is also
called from the error paths of xen_9pfs_pdu_vmarshal/vunmarshal, which
run inside the PDU's own coroutine. v9fs_reset() is not safe to be
called there.

We could remove the direct call to xen_9pfs_disconnect() from
xen_9pfs_pdu_vmarshal/vunmarshal because they already change the state
to XenbusStateClosing, which should result in the same 


> >      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),
> 
> 
> 
> 

Reply via email to