[PATCH 0/3] 9p: fix guest-triggered Treaddir/ACPI eject UAF

[PATCH 0/3] 9p: fix guest-triggered Treaddir/ACPI eject UAF

[Christian Schoenebeck]

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

[PATCH 3/3] hw/9pfs/xen: drain in-flight PDUs before xen-9p disconnect

[Christian Schoenebeck]

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 <qemu_oss@crudebyte.com>
---
 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);
+
     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),
-- 
2.47.3

Re: [PATCH 3/3] hw/9pfs/xen: drain in-flight PDUs before xen-9p disconnect

[Christian Schoenebeck]

Hi Stefano,

do you might have a chance to look at this Xen patch?

/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 <qemu_oss@crudebyte.com>
> ---
>  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);
> +
>      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),

Re: [PATCH 3/3] hw/9pfs/xen: drain in-flight PDUs before xen-9p disconnect

[Stefano Stabellini]

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 <qemu_oss@crudebyte.com>
> > ---
> >  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),
> 
> 
> 
> 

Re: [PATCH 3/3] hw/9pfs/xen: drain in-flight PDUs before xen-9p disconnect

[Christian Schoenebeck]

On Saturday, 18 July 2026 02:46:36 CEST Stefano Stabellini wrote:
> 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

Thanks for looking at this, much appreciated!

> > 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 <qemu_oss@crudebyte.com>
> > > ---
> > > 
> > >  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.

Well, xen_9pfs_pdu_vmarshal() / xen_9pfs_pdu_vunmarshal() are both called on 
main thread, and xen_be_disconnect() has a guard that prevents the disconnect 
handler being called twice (more about that later), however you are right that 
these two functions run within coroutines. Which then leads to the following 
problem in v9fs_reset():

    while (!QLIST_EMPTY(&s->active_list)) {
        aio_poll(qemu_get_aio_context(), true);
    }

This loop would then run forever, as the coroutine calling v9fs_reset() is on 
the active_list, hence this list would never turn empty and the loop condition  
never turn false.

Furthermore aio_poll() is marked as no_coroutine_fn:

include/qemu/aio.h:bool no_coroutine_fn aio_poll(AioContext *ctx, bool 
blocking);

So aio_poll() should actually not be called in a coroutine context at all.
 
> 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

The problem with this approach is that xen_9pfs_pdu_vmarshal() / 
xen_9pfs_pdu_vunmarshal() would still call:

    xen_be_set_state(&xen_9pfs->xendev, XenbusStateClosing);

And the previously mentioned guard in xen_be_disconnect() for not calling the 
disconnect callback more than once, looks like this:

    if (xendev->be_state != XenbusStateClosing &&
        xendev->be_state != XenbusStateClosed  &&
        xendev->ops->disconnect) {
        xendev->ops->disconnect(xendev);
    }

Hence if this (v)unmarshal error path was triggered, the disconnect handler 
would then actually never be executed. And that's apparently the reason why 
these two functions do call xen_9pfs_disconnect() explicitly in their error 
path right now.

What I think might work though, was replacing the current direct 
xen_9pfs_disconnect() calls by deferred ones, something like:

    aio_bh_schedule_oneshot(... xen_9pfs_disconnect ...);

Because xen_9pfs_disconnect() would then run both on main thread and not run 
in a coroutine context. So it should turn it safe.

I'll prepare a v2 with the latter solution.

/Christian

[PATCH 2/3] hw/9pfs/virtio: disable hotpluggable property of virtio-9p device

[Christian Schoenebeck]

Harden security by disabling hotpluggable property, to prevent
issues like fixed in the previous commit.

Virtio-9p is a pass-through file-sharing device that provides a
guest mount of a host filesystem tree. Unlike block or network
devices, guest-triggered hotplug of the 9p device has no practical
use case: the guest cannot recover from the device removal, and there
is no protocol-level device-loss scenario as with block or ethernet
devices.

Prevent guest-triggered hotplug by marking the device as
non-hotpluggable. Device removal via QMP is not affected by this, as
the QMP removal path is not reading the device's hotpluggable field
at all.

Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
---
 hw/9pfs/virtio-9p-device.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index 1ec48fc9e0..ba43fd22d2 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -273,6 +273,7 @@ static void virtio_9p_class_init(ObjectClass *klass, const void *data)
 
     device_class_set_props(dc, virtio_9p_properties);
     dc->vmsd = &vmstate_virtio_9p;
+    dc->hotpluggable = false;
     set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
     vdc->realize = virtio_9p_device_realize;
     vdc->unrealize = virtio_9p_device_unrealize;
-- 
2.47.3

Re: [PATCH 2/3] hw/9pfs/virtio: disable hotpluggable property of virtio-9p device

[Igor Mammedov]

On Thu, 9 Jul 2026 15:50:36 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> Harden security by disabling hotpluggable property, to prevent
> issues like fixed in the previous commit.
> 
> Virtio-9p is a pass-through file-sharing device that provides a
> guest mount of a host filesystem tree. Unlike block or network
> devices, guest-triggered hotplug of the 9p device has no practical
> use case: the guest cannot recover from the device removal, and there
> is no protocol-level device-loss scenario as with block or ethernet
> devices.

hmh, I'm no maintainer of 9pfs, but to me it looks like any other
storage device.
One should be able to unmount/stop using it and unplug
(it doesn't really matter if unplug is triggered by guest or host side).

> Prevent guest-triggered hotplug by marking the device as
> non-hotpluggable. Device removal via QMP is not affected by this, as
> the QMP removal path is not reading the device's hotpluggable field
> at all.
> 
> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
> ---
>  hw/9pfs/virtio-9p-device.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
> index 1ec48fc9e0..ba43fd22d2 100644
> --- a/hw/9pfs/virtio-9p-device.c
> +++ b/hw/9pfs/virtio-9p-device.c
> @@ -273,6 +273,7 @@ static void virtio_9p_class_init(ObjectClass *klass, const void *data)
>  
>      device_class_set_props(dc, virtio_9p_properties);
>      dc->vmsd = &vmstate_virtio_9p;
> +    dc->hotpluggable = false;
>      set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
>      vdc->realize = virtio_9p_device_realize;
>      vdc->unrealize = virtio_9p_device_unrealize;

Re: [PATCH 2/3] hw/9pfs/virtio: disable hotpluggable property of virtio-9p device

[Christian Schoenebeck]

On Friday, 10 July 2026 09:37:37 CEST Igor Mammedov wrote:
> On Thu, 9 Jul 2026 15:50:36 +0200
> 
> Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> > Harden security by disabling hotpluggable property, to prevent
> > issues like fixed in the previous commit.
> > 
> > Virtio-9p is a pass-through file-sharing device that provides a
> > guest mount of a host filesystem tree. Unlike block or network
> > devices, guest-triggered hotplug of the 9p device has no practical
> > use case: the guest cannot recover from the device removal, and there
> > is no protocol-level device-loss scenario as with block or ethernet
> > devices.
> 
> hmh, I'm no maintainer of 9pfs, but to me it looks like any other
> storage device.
> One should be able to unmount/stop using it and unplug
> (it doesn't really matter if unplug is triggered by guest or host side).

Guest could still unmount and stop using the 9pfs device. But why should guest 
be able to unrealize the 9pfs device at any time? What should be the purpose 
for this particular device?

/Christian

Re: [PATCH 2/3] hw/9pfs/virtio: disable hotpluggable property of virtio-9p device

[Igor Mammedov]

On Fri, 10 Jul 2026 10:06:29 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> On Friday, 10 July 2026 09:37:37 CEST Igor Mammedov wrote:
> > On Thu, 9 Jul 2026 15:50:36 +0200
> > 
> > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:  
> > > Harden security by disabling hotpluggable property, to prevent
> > > issues like fixed in the previous commit.
> > > 
> > > Virtio-9p is a pass-through file-sharing device that provides a
> > > guest mount of a host filesystem tree. Unlike block or network
> > > devices, guest-triggered hotplug of the 9p device has no practical
> > > use case: the guest cannot recover from the device removal, and there
> > > is no protocol-level device-loss scenario as with block or ethernet
> > > devices.  
> > 
> > hmh, I'm no maintainer of 9pfs, but to me it looks like any other
> > storage device.
> > One should be able to unmount/stop using it and unplug
> > (it doesn't really matter if unplug is triggered by guest or host side).  
> 
> Guest could still unmount and stop using the 9pfs device. But why should guest 
> be able to unrealize the 9pfs device at any time? What should be the purpose 
> for this particular device?

unrealize is part of unplug process, at the end of unplug no device should be left attached.
You might not need/use it but others might be using it actively.

--- 

In QEMU impl. it's cooperative process (we don't do surprise removal of PCI devices),
where host triggers plug/unplug process and guest side completes it, by:
  1. freeing resources on its side 1st (hopefully)
  2. issuing eject/poweroff (either via ACPI or native PCIE-HP/SHPC interface)

If guest fails to do #1 it is able to abort process, or it might continue and
do #2 with a risk of loosing data but it's guest's business/policy.

If you need to disable hotplug for a specific PCI device instance,
use 'hotplug' CLI option on pcie bridge. If you use other than PCI variant
of virtio device, then unplug as you describe it isn't reachable, and if it
should be disabled in code, it's up to actual frontend device that exposes
underlying virtio one.

> /Christian
> 
> 

Re: [PATCH 2/3] hw/9pfs/virtio: disable hotpluggable property of virtio-9p device

[Christian Schoenebeck]

On Friday, 10 July 2026 12:23:45 CEST Igor Mammedov wrote:
> On Fri, 10 Jul 2026 10:06:29 +0200
> 
> Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> > On Friday, 10 July 2026 09:37:37 CEST Igor Mammedov wrote:
> > > On Thu, 9 Jul 2026 15:50:36 +0200
> > > 
> > > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> > > > Harden security by disabling hotpluggable property, to prevent
> > > > issues like fixed in the previous commit.
> > > > 
> > > > Virtio-9p is a pass-through file-sharing device that provides a
> > > > guest mount of a host filesystem tree. Unlike block or network
> > > > devices, guest-triggered hotplug of the 9p device has no practical
> > > > use case: the guest cannot recover from the device removal, and there
> > > > is no protocol-level device-loss scenario as with block or ethernet
> > > > devices.
> > > 
> > > hmh, I'm no maintainer of 9pfs, but to me it looks like any other
> > > storage device.
> > > One should be able to unmount/stop using it and unplug
> > > (it doesn't really matter if unplug is triggered by guest or host side).
> > 
> > Guest could still unmount and stop using the 9pfs device. But why should
> > guest be able to unrealize the 9pfs device at any time? What should be
> > the purpose for this particular device?
> 
> unrealize is part of unplug process, at the end of unplug no device should
> be left attached. You might not need/use it but others might be using it
> actively.

I got that, but my question was: why would they want to do that with an 9pfs 
device? Can you make up any real-life scenario why a guest might want to 
remove a 9p device, given there is no way for them to bring the device back?

Looking at the fixed issue (patch 1), my impression was that original 9p 
server developers were unaware that guest can actually trigger a device 
unrealize via ACPI eject. Most probably because hotplugging is enabled by 
default for all devices in QEMU

Independent of this patch here, I'm therefore currently investigating whether 
enabling hotplugging by default in QEMU actually make sense. To me, this 
should be an opt-in, not the other way around. Because device developers 
should make sure that ejecting a device a) makes sense for the device type in 
the first place and most importantly b) that ejecting the device works 
(without data loss and without negative security impact, as it was the case 
here).

> ---
> 
> In QEMU impl. it's cooperative process (we don't do surprise removal of PCI
> devices), where host triggers plug/unplug process and guest side completes
> it, by: 1. freeing resources on its side 1st (hopefully)
>   2. issuing eject/poweroff (either via ACPI or native PCIE-HP/SHPC
> interface)
> 
> If guest fails to do #1 it is able to abort process, or it might continue
> and do #2 with a risk of loosing data but it's guest's business/policy.
> 
> If you need to disable hotplug for a specific PCI device instance,
> use 'hotplug' CLI option on pcie bridge. If you use other than PCI variant
> of virtio device, then unplug as you describe it isn't reachable, and if it
> should be disabled in code, it's up to actual frontend device that exposes
> underlying virtio one.

What does that have to do with this issue here? The normal 9pfs live-cycle is 
to create the 9p device at QEMU startup, and unrealizing the 9p device at QEMU 
shutdown.

If guest does an ACPI eject, then the only way to bring the 9p device back is 
to restart QEMU with the required -virtfs / -fsdev -device CLI options.

The Linux 9p client (guest) does never trigger an ACPI reject on unmount. It 
just marks the virtio channel as unused. If client would eject it, it would 
not be possible for guest to re-mount it later on.

/Christian

Re: [PATCH 2/3] hw/9pfs/virtio: disable hotpluggable property of virtio-9p device

[Igor Mammedov]

On Fri, 10 Jul 2026 12:49:06 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> On Friday, 10 July 2026 12:23:45 CEST Igor Mammedov wrote:
> > On Fri, 10 Jul 2026 10:06:29 +0200
> > 
> > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:  
> > > On Friday, 10 July 2026 09:37:37 CEST Igor Mammedov wrote:  
> > > > On Thu, 9 Jul 2026 15:50:36 +0200
> > > > 
> > > > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:  
> > > > > Harden security by disabling hotpluggable property, to prevent
> > > > > issues like fixed in the previous commit.
> > > > > 
> > > > > Virtio-9p is a pass-through file-sharing device that provides a
> > > > > guest mount of a host filesystem tree. Unlike block or network
> > > > > devices, guest-triggered hotplug of the 9p device has no practical
> > > > > use case: the guest cannot recover from the device removal, and there
> > > > > is no protocol-level device-loss scenario as with block or ethernet
> > > > > devices.  
> > > > 
> > > > hmh, I'm no maintainer of 9pfs, but to me it looks like any other
> > > > storage device.
> > > > One should be able to unmount/stop using it and unplug
> > > > (it doesn't really matter if unplug is triggered by guest or host side).  
> > > 
> > > Guest could still unmount and stop using the 9pfs device. But why should
> > > guest be able to unrealize the 9pfs device at any time? What should be
> > > the purpose for this particular device?  
> > 
> > unrealize is part of unplug process, at the end of unplug no device should
> > be left attached. You might not need/use it but others might be using it
> > actively.  
> 
> I got that, but my question was: why would they want to do that with an 9pfs 
> device? Can you make up any real-life scenario why a guest might want to 
> remove a 9p device, given there is no way for them to bring the device back?

note: I'm looking from pov of hotpluggable PCI device and generic hotplug infra, only.

it's not guest users directly, it's how hotplug flow works for various guest OSes:

1. host plugs device in (-device or device_add)
2. guest OS get's notified one way or another and does what ever guest side
   init needed (incl. mounting share in 9pfs case)

opposite flow:
1. host does device_del (basically notify guest to remove device)
2. guest OS frees resources and tells qemu to delete device 
3. qemu process remove event (which incl. unrealize as part of destroying device)

Of cause guest if free to eject device without signal from host,
(I could imagine: get some file from share once and then guest releases
no longer need resource).
 
> Looking at the fixed issue (patch 1), my impression was that original 9p 
> server developers were unaware that guest can actually trigger a device 
> unrealize via ACPI eject.

I'd say it's a bug, and you are trying to fix it in patch #1

> Most probably because hotplugging is enabled by 
> default for all devices in QEMU

it is on by default for PCI devices but also heavily depends on used
configuration (where/what is plugged).

> Independent of this patch here, I'm therefore currently investigating whether 
> enabling hotplugging by default in QEMU actually make sense. To me, this 
> should be an opt-in, not the other way around. Because device developers 
> should make sure that ejecting a device a) makes sense for the device type in 
> the first place and most importantly b) that ejecting the device works 
> (without data loss and without negative security impact, as it was the case 
> here).

well, hotplug is on by default for PCI devices. It is unlikely we would
flip default now.

It might make sense to disable hotplug in mmio frontend if such exists,
but then it's pointless as there is no way to trigger unplug for it
(both host or guest side)

> 
> > ---
> > 
> > In QEMU impl. it's cooperative process (we don't do surprise removal of PCI
> > devices), where host triggers plug/unplug process and guest side completes
> > it, by: 1. freeing resources on its side 1st (hopefully)
> >   2. issuing eject/poweroff (either via ACPI or native PCIE-HP/SHPC
> > interface)
> > 
> > If guest fails to do #1 it is able to abort process, or it might continue
> > and do #2 with a risk of loosing data but it's guest's business/policy.
> > 
> > If you need to disable hotplug for a specific PCI device instance,
> > use 'hotplug' CLI option on pcie bridge. If you use other than PCI variant
> > of virtio device, then unplug as you describe it isn't reachable, and if it
> > should be disabled in code, it's up to actual frontend device that exposes
> > underlying virtio one.  
> 
> What does that have to do with this issue here? The normal 9pfs live-cycle is 
> to create the 9p device at QEMU startup, and unrealizing the 9p device at QEMU 
> shutdown.
> 
> If guest does an ACPI eject, then the only way to bring the 9p device back is 
> to restart QEMU with the required -virtfs / -fsdev -device CLI options.

one can use device_add to put it back into running machine.

given mention of ACPI eject, 9pfs flavor actually used is PCI variant =>
all PCI device features apply incl. hot(un)plug.
If hotplug is not desirable for particular device instance, one can disable
it on CLI.

that said,
if 9pfs maintainer deem that it shouldn't be hotpluggable and it's
safe to remove capability, I'm fine with that too, just fix commit message
section wrt QMP removal and perhaps move the flag into front-end impl of
the device.

BTW: always describe a way to reproduce problem (cover letter and/or patch)
so that reviewer could see whole flow. Otherwise one has to guess what/how it gets
broken based on context.
 
> The Linux 9p client (guest) does never trigger an ACPI reject on unmount. It 
> just marks the virtio channel as unused. If client would eject it, it would 
> not be possible for guest to re-mount it later on.

no argument here

> /Christian
> 
> 
> 
> 

Re: [PATCH 2/3] hw/9pfs/virtio: disable hotpluggable property of virtio-9p device

[Christian Schoenebeck]

On Friday, 10 July 2026 14:51:49 CEST Igor Mammedov wrote:
> On Fri, 10 Jul 2026 12:49:06 +0200
> 
> Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> > On Friday, 10 July 2026 12:23:45 CEST Igor Mammedov wrote:
[...]
> note: I'm looking from pov of hotpluggable PCI device and generic hotplug
> infra, only.

That's okay, but so far I don't see the relevance for this particular 9p 
device.
 
> it's not guest users directly, it's how hotplug flow works for various guest
> OSes:
> 
> 1. host plugs device in (-device or device_add)
> 2. guest OS get's notified one way or another and does what ever guest side
>    init needed (incl. mounting share in 9pfs case)

That's not affected by this patch, right?

> opposite flow:
> 1. host does device_del (basically notify guest to remove device)
> 2. guest OS frees resources and tells qemu to delete device
> 3. qemu process remove event (which incl. unrealize as part of destroying
> device)

And that's not affected by this patch either, right?

> Of cause guest if free to eject device without signal from host,

OK, here is the point where we deviate: you are apparently seeing this from a 
purely theoretical PoV.

I am facing reality: for several years I'm the only person taking care about 
this piece of code at all (on a side channel, for free, next to my actual 
work). And for several months I get AI generated security reports thrown at 
me, where I have to a) filter legit ones, and b) fix those legit security 
issues.

For that reason, I am tightening security wherever I can, to prevent further 
flood.

So the question here is: are you concerned about a real-life issue being 
introduced by disabling hotplugging for 9pfs specifically?

> (I could imagine: get some file from share once and then guest releases
> no longer need resource).

It's a pass-through file system. Ejecting the device does not really free a 
noteworthy amount of resources.

> > Looking at the fixed issue (patch 1), my impression was that original 9p
> > server developers were unaware that guest can actually trigger a device
> > unrealize via ACPI eject.
> 
> I'd say it's a bug, and you are trying to fix it in patch #1
> 
> > Most probably because hotplugging is enabled by
> > default for all devices in QEMU
> 
> it is on by default for PCI devices but also heavily depends on used
> configuration (where/what is plugged).

Exactly! And I was trying to explain, that for this particular use case 
(9pfs), I don't see any real-live use-case for allowing a guest to eject the 
9p device at runtime.

So why allowing it? Just for fun?

> > Independent of this patch here, I'm therefore currently investigating
> > whether enabling hotplugging by default in QEMU actually make sense. To
> > me, this should be an opt-in, not the other way around. Because device
> > developers should make sure that ejecting a device a) makes sense for the
> > device type in the first place and most importantly b) that ejecting the
> > device works (without data loss and without negative security impact, as
> > it was the case here).
> 
> well, hotplug is on by default for PCI devices. It is unlikely we would
> flip default now.

I am investigating to flip the default value for good reasons: I made a quick 
scan on the huge list of devices in QEMU and found quite a number that are 
affected by a similar UAF issue on guest ACPI eject. What do those devices 
have in common? Hotplug is enabled by default, not explicitly by the 
respective device.

> that said, if 9pfs maintainer deem that it shouldn't be hotpluggable and 
> it's safe to remove capability,

That's me, unfortunately. Singular.

> I'm fine with that too, just fix commit message
> section wrt QMP removal and perhaps move the flag into front-end impl of
> the device.

Yeah, I just noticed that as well, that this should rather go to the PCI 
bridge device. This patch applied it to the inner device, which is wrong.

> BTW: always describe a way to reproduce problem (cover letter and/or patch)
> so that reviewer could see whole flow. Otherwise one has to guess what/how
> it gets broken based on context.

The original report (private) is linked by patch 1:
https://gitlab.com/qemu-project/qemu/-/work_items/3937

Anyway, I'll think some more days about this, whether I should fix or drop the 
patch.

If you have more feedback, always appreciated of course.

Thanks!

/Christian

Re: [PATCH 2/3] hw/9pfs/virtio: disable hotpluggable property of virtio-9p device

[Daniel P. Berrangé]

On Fri, Jul 10, 2026 at 04:31:51PM +0200, Christian Schoenebeck wrote:
> On Friday, 10 July 2026 14:51:49 CEST Igor Mammedov wrote:
> > On Fri, 10 Jul 2026 12:49:06 +0200
> > 
> > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> > > On Friday, 10 July 2026 12:23:45 CEST Igor Mammedov wrote:
> [...]
> > note: I'm looking from pov of hotpluggable PCI device and generic hotplug
> > infra, only.
> 
> That's okay, but so far I don't see the relevance for this particular 9p 
> device.
>  
> > it's not guest users directly, it's how hotplug flow works for various guest
> > OSes:
> > 
> > 1. host plugs device in (-device or device_add)
> > 2. guest OS get's notified one way or another and does what ever guest side
> >    init needed (incl. mounting share in 9pfs case)
> 
> That's not affected by this patch, right?
> 
> > opposite flow:
> > 1. host does device_del (basically notify guest to remove device)
> > 2. guest OS frees resources and tells qemu to delete device
> > 3. qemu process remove event (which incl. unrealize as part of destroying
> > device)
> 
> And that's not affected by this patch either, right?
> 
> > Of cause guest if free to eject device without signal from host,
> 
> OK, here is the point where we deviate: you are apparently seeing this from a 
> purely theoretical PoV.
> 
> I am facing reality: for several years I'm the only person taking care about 
> this piece of code at all (on a side channel, for free, next to my actual 
> work). And for several months I get AI generated security reports thrown at 
> me, where I have to a) filter legit ones, and b) fix those legit security 
> issues.
> 
> For that reason, I am tightening security wherever I can, to prevent further 
> flood.
> 
> So the question here is: are you concerned about a real-life issue being 
> introduced by disabling hotplugging for 9pfs specifically?
> 
> > (I could imagine: get some file from share once and then guest releases
> > no longer need resource).
> 
> It's a pass-through file system. Ejecting the device does not really free a 
> noteworthy amount of resources.
> 
> > > Looking at the fixed issue (patch 1), my impression was that original 9p
> > > server developers were unaware that guest can actually trigger a device
> > > unrealize via ACPI eject.
> > 
> > I'd say it's a bug, and you are trying to fix it in patch #1
> > 
> > > Most probably because hotplugging is enabled by
> > > default for all devices in QEMU
> > 
> > it is on by default for PCI devices but also heavily depends on used
> > configuration (where/what is plugged).
> 
> Exactly! And I was trying to explain, that for this particular use case 
> (9pfs), I don't see any real-live use-case for allowing a guest to eject the 
> 9p device at runtime.
> 
> So why allowing it? Just for fun?

I don't think it would be usual for a guest to unilaterally "eject"
a 9p device. A host initiated PCI hot-unplug request from QEMU
would ultimately trigger the guest eject code path though. IMHO
host initiated hotplug+unplug is a valid use for any device. For
9p the use is to provide a time limited data share to some workload
in the guest. There are many other ways that can be done too,
USB MTP, or virtiofs, or in guest with SFTP or WebDAV, etc. 


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH 2/3] hw/9pfs/virtio: disable hotpluggable property of virtio-9p device

[Igor Mammedov]

On Fri, 10 Jul 2026 15:40:04 +0100
Daniel P. Berrangé <berrange@redhat.com> wrote:

> On Fri, Jul 10, 2026 at 04:31:51PM +0200, Christian Schoenebeck wrote:
> > On Friday, 10 July 2026 14:51:49 CEST Igor Mammedov wrote:  
> > > On Fri, 10 Jul 2026 12:49:06 +0200
> > > 
> > > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:  
> > > > On Friday, 10 July 2026 12:23:45 CEST Igor Mammedov wrote:  
> > [...]  
> > > note: I'm looking from pov of hotpluggable PCI device and generic hotplug
> > > infra, only.  
> > 
> > That's okay, but so far I don't see the relevance for this particular 9p 
> > device.
> >    
> > > it's not guest users directly, it's how hotplug flow works for various guest
> > > OSes:
> > > 
> > > 1. host plugs device in (-device or device_add)
> > > 2. guest OS get's notified one way or another and does what ever guest side
> > >    init needed (incl. mounting share in 9pfs case)  
> > 
> > That's not affected by this patch, right?
> >   
> > > opposite flow:
> > > 1. host does device_del (basically notify guest to remove device)
> > > 2. guest OS frees resources and tells qemu to delete device
> > > 3. qemu process remove event (which incl. unrealize as part of destroying
> > > device)  
> > 
> > And that's not affected by this patch either, right?

the patch would break unplug flow by effectively removing 'eject' knob 
from guest side, which is part of unplug flow.

> >   
> > > Of cause guest if free to eject device without signal from host,  
> > 
> > OK, here is the point where we deviate: you are apparently seeing this from a 
> > purely theoretical PoV.
> > 
> > I am facing reality: for several years I'm the only person taking care about 
> > this piece of code at all (on a side channel, for free, next to my actual 
> > work). And for several months I get AI generated security reports thrown at 
> > me, where I have to a) filter legit ones, and b) fix those legit security 
> > issues.
> > 
> > For that reason, I am tightening security wherever I can, to prevent further 
> > flood.
> > 
> > So the question here is: are you concerned about a real-life issue being 
> > introduced by disabling hotplugging for 9pfs specifically?

my concern is that there might be users that use unplug despite present bug(s),
and the patch would regress their usecase.

If unplug 'works', then we shouldn't disable it.
If it's never worked to begin with, it should be safe to disable it.

> > > (I could imagine: get some file from share once and then guest releases
> > > no longer need resource).  
> > 
> > It's a pass-through file system. Ejecting the device does not really free a 
> > noteworthy amount of resources.
> >
> > > > Looking at the fixed issue (patch 1), my impression was that original 9p
> > > > server developers were unaware that guest can actually trigger a device
> > > > unrealize via ACPI eject.  
> > > 
> > > I'd say it's a bug, and you are trying to fix it in patch #1
> > >   
> > > > Most probably because hotplugging is enabled by
> > > > default for all devices in QEMU  
> > > 
> > > it is on by default for PCI devices but also heavily depends on used
> > > configuration (where/what is plugged).  
> > 
> > Exactly! And I was trying to explain, that for this particular use case 
> > (9pfs), I don't see any real-live use-case for allowing a guest to eject the 
> > 9p device at runtime.
> > 
> > So why allowing it? Just for fun?  
> 
> I don't think it would be usual for a guest to unilaterally "eject"
> a 9p device. A host initiated PCI hot-unplug request from QEMU
> would ultimately trigger the guest eject code path though. IMHO
> host initiated hotplug+unplug is a valid use for any device. For
> 9p the use is to provide a time limited data share to some workload
> in the guest. There are many other ways that can be done too,
> USB MTP, or virtiofs, or in guest with SFTP or WebDAV, etc. 
> 
> 
> With regards,
> Daniel

Re: [PATCH 2/3] hw/9pfs/virtio: disable hotpluggable property of virtio-9p device

[Christian Schoenebeck]

On Monday, 13 July 2026 09:49:35 CEST Igor Mammedov wrote:
> On Fri, 10 Jul 2026 15:40:04 +0100
> 
> Daniel P. Berrangé <berrange@redhat.com> wrote:
> > On Fri, Jul 10, 2026 at 04:31:51PM +0200, Christian Schoenebeck wrote:
> > > On Friday, 10 July 2026 14:51:49 CEST Igor Mammedov wrote:
> > > > On Fri, 10 Jul 2026 12:49:06 +0200
> > > > 
> > > > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> > > > > On Friday, 10 July 2026 12:23:45 CEST Igor Mammedov wrote:
> > > [...]
> > > 
> > > > note: I'm looking from pov of hotpluggable PCI device and generic
> > > > hotplug
> > > > infra, only.
> > > 
> > > That's okay, but so far I don't see the relevance for this particular 9p
> > > device.
> > > 
> > > > it's not guest users directly, it's how hotplug flow works for various
> > > > guest OSes:
> > > > 
> > > > 1. host plugs device in (-device or device_add)
> > > > 2. guest OS get's notified one way or another and does what ever guest
> > > > side
> > > > 
> > > >    init needed (incl. mounting share in 9pfs case)
> > > 
> > > That's not affected by this patch, right?
> > > 
> > > > opposite flow:
> > > > 1. host does device_del (basically notify guest to remove device)
> > > > 2. guest OS frees resources and tells qemu to delete device
> > > > 3. qemu process remove event (which incl. unrealize as part of
> > > > destroying
> > > > device)
> > > 
> > > And that's not affected by this patch either, right?
> 
> the patch would break unplug flow by effectively removing 'eject' knob
> from guest side, which is part of unplug flow.

These are two different things: device_del would not be affected by this. 

1. Ejecting the device from host side e.g. via QMP would still work.

vs.

2. Ejecting from guest side OTOH would be disabled.

It is also different from regular block devices where you have convenient ways
to eject a block device on guest OSes. For a virtio-9p device it is not that
easy.

> > > OK, here is the point where we deviate: you are apparently seeing this
> > > from a purely theoretical PoV.
> > > 
> > > I am facing reality: for several years I'm the only person taking care
> > > about this piece of code at all (on a side channel, for free, next to
> > > my actual work). And for several months I get AI generated security
> > > reports thrown at me, where I have to a) filter legit ones, and b) fix
> > > those legit security issues.
> > > 
> > > For that reason, I am tightening security wherever I can, to prevent
> > > further flood.
> > > 
> > > So the question here is: are you concerned about a real-life issue being
> > > introduced by disabling hotplugging for 9pfs specifically?
> 
> my concern is that there might be users that use unplug despite present
> bug(s), and the patch would regress their usecase.

I already got that with your first message, and directly asked which use-case
that would be exactly.

Just saying there might be one theoretical unknown person on this planet who
might be using it, and nobody even being capable to imagine what for, does not
justify keeping an exotic feature (again: context 9pfs) that already had
negative impact on security for anybody else, especially for such a low man
power codebase like 9pfs.

This is similar to a discussion in the past about retaining support for older
macOS versions in QEMU:

https://lore.kernel.org/qemu-devel/CAFEAcA9VnQCG3r28BOLr_qXLRM2V68r3oK4ZfY9+bVz2j1oSyA@mail.gmail.com/

Anyway, I decided to drop this patch and retaining guest eject for now.

However if there is any other kind of bug, especially of security nature, then
I will definitely disable guest eject unless proven there are justified real-
world users or somebody willing to step-in and keeping care of.

/Christian

Re: [PATCH 2/3] hw/9pfs/virtio: disable hotpluggable property of virtio-9p device

[Daniel P. Berrangé]

On Fri, Jul 17, 2026 at 04:05:42PM +0200, Christian Schoenebeck wrote:
> On Monday, 13 July 2026 09:49:35 CEST Igor Mammedov wrote:
> > On Fri, 10 Jul 2026 15:40:04 +0100
> > 
> > Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > On Fri, Jul 10, 2026 at 04:31:51PM +0200, Christian Schoenebeck wrote:
> > > > On Friday, 10 July 2026 14:51:49 CEST Igor Mammedov wrote:
> > > > > On Fri, 10 Jul 2026 12:49:06 +0200
> > > > > 
> > > > > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> > > > > > On Friday, 10 July 2026 12:23:45 CEST Igor Mammedov wrote:
> > > > [...]
> > > > 
> > > > > note: I'm looking from pov of hotpluggable PCI device and generic
> > > > > hotplug
> > > > > infra, only.
> > > > 
> > > > That's okay, but so far I don't see the relevance for this particular 9p
> > > > device.
> > > > 
> > > > > it's not guest users directly, it's how hotplug flow works for various
> > > > > guest OSes:
> > > > > 
> > > > > 1. host plugs device in (-device or device_add)
> > > > > 2. guest OS get's notified one way or another and does what ever guest
> > > > > side
> > > > > 
> > > > >    init needed (incl. mounting share in 9pfs case)
> > > > 
> > > > That's not affected by this patch, right?
> > > > 
> > > > > opposite flow:
> > > > > 1. host does device_del (basically notify guest to remove device)
> > > > > 2. guest OS frees resources and tells qemu to delete device
> > > > > 3. qemu process remove event (which incl. unrealize as part of
> > > > > destroying
> > > > > device)
> > > > 
> > > > And that's not affected by this patch either, right?
> > 
> > the patch would break unplug flow by effectively removing 'eject' knob
> > from guest side, which is part of unplug flow.
> 
> These are two different things: device_del would not be affected by this. 
> 
> 1. Ejecting the device from host side e.g. via QMP would still work.
> 
> vs.
> 
> 2. Ejecting from guest side OTOH would be disabled.
> 
> It is also different from regular block devices where you have convenient ways
> to eject a block device on guest OSes. For a virtio-9p device it is not that
> easy.

Igor can correct me if I'm wrong, but IIUC there's no distinction
to those 2 scenarios from the guest POV.

A "device_del" in QMP does not actually delete a device from the
QEMU POV.  Rather it triggers an ACPI notification to the geust
OS, that the operator wants to unplug the device.  The guest OS
then honours (or not) that by initiating a guest side "eject".
IOW disabling guest initiated eject would break device_del too
AFAIK.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH 2/3] hw/9pfs/virtio: disable hotpluggable property of virtio-9p device

[Igor Mammedov]

On Fri, 17 Jul 2026 15:16:14 +0100
Daniel P. Berrangé <berrange@redhat.com> wrote:

> On Fri, Jul 17, 2026 at 04:05:42PM +0200, Christian Schoenebeck wrote:
> > On Monday, 13 July 2026 09:49:35 CEST Igor Mammedov wrote:  
> > > On Fri, 10 Jul 2026 15:40:04 +0100
> > > 
> > > Daniel P. Berrangé <berrange@redhat.com> wrote:  
> > > > On Fri, Jul 10, 2026 at 04:31:51PM +0200, Christian Schoenebeck wrote:  
> > > > > On Friday, 10 July 2026 14:51:49 CEST Igor Mammedov wrote:  
> > > > > > On Fri, 10 Jul 2026 12:49:06 +0200
> > > > > > 
> > > > > > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:  
> > > > > > > On Friday, 10 July 2026 12:23:45 CEST Igor Mammedov wrote:  
> > > > > [...]
> > > > >   
> > > > > > note: I'm looking from pov of hotpluggable PCI device and generic
> > > > > > hotplug
> > > > > > infra, only.  
> > > > > 
> > > > > That's okay, but so far I don't see the relevance for this particular 9p
> > > > > device.
> > > > >   
> > > > > > it's not guest users directly, it's how hotplug flow works for various
> > > > > > guest OSes:
> > > > > > 
> > > > > > 1. host plugs device in (-device or device_add)
> > > > > > 2. guest OS get's notified one way or another and does what ever guest
> > > > > > side
> > > > > > 
> > > > > >    init needed (incl. mounting share in 9pfs case)  
> > > > > 
> > > > > That's not affected by this patch, right?
> > > > >   
> > > > > > opposite flow:
> > > > > > 1. host does device_del (basically notify guest to remove device)
> > > > > > 2. guest OS frees resources and tells qemu to delete device
> > > > > > 3. qemu process remove event (which incl. unrealize as part of
> > > > > > destroying
> > > > > > device)  
> > > > > 
> > > > > And that's not affected by this patch either, right?  
> > > 
> > > the patch would break unplug flow by effectively removing 'eject' knob
> > > from guest side, which is part of unplug flow.  
> > 
> > These are two different things: device_del would not be affected by this. 
> > 
> > 1. Ejecting the device from host side e.g. via QMP would still work.
> > 
> > vs.
> > 
> > 2. Ejecting from guest side OTOH would be disabled.
> > 
> > It is also different from regular block devices where you have convenient ways
> > to eject a block device on guest OSes. For a virtio-9p device it is not that
> > easy.  
> 
> Igor can correct me if I'm wrong, but IIUC there's no distinction
> to those 2 scenarios from the guest POV.
> 
> A "device_del" in QMP does not actually delete a device from the
> QEMU POV.  Rather it triggers an ACPI notification to the geust
> OS, that the operator wants to unplug the device.  The guest OS
> then honours (or not) that by initiating a guest side "eject".
> IOW disabling guest initiated eject would break device_del too
> AFAIK.

That's how it works.
Sorry if I wasn't able to convey the message in my previous replies.

> 
> With regards,
> Daniel

Re: [PATCH 2/3] hw/9pfs/virtio: disable hotpluggable property of virtio-9p device

[Christian Schoenebeck]

On Monday, 20 July 2026 13:23:37 CEST Igor Mammedov wrote:
> On Fri, 17 Jul 2026 15:16:14 +0100
> 
> Daniel P. Berrangé <berrange@redhat.com> wrote:
> > On Fri, Jul 17, 2026 at 04:05:42PM +0200, Christian Schoenebeck wrote:
> > > On Monday, 13 July 2026 09:49:35 CEST Igor Mammedov wrote:
[...]
> > > > the patch would break unplug flow by effectively removing 'eject' knob
> > > > from guest side, which is part of unplug flow.
> > > 
> > > These are two different things: device_del would not be affected by
> > > this.
> > > 
> > > 1. Ejecting the device from host side e.g. via QMP would still work.
> > > 
> > > vs.
> > > 
> > > 2. Ejecting from guest side OTOH would be disabled.
> > > 
> > > It is also different from regular block devices where you have
> > > convenient ways to eject a block device on guest OSes. For a virtio-9p
> > > device it is not that easy.
> > 
> > Igor can correct me if I'm wrong, but IIUC there's no distinction
> > to those 2 scenarios from the guest POV.
> > 
> > A "device_del" in QMP does not actually delete a device from the
> > QEMU POV.  Rather it triggers an ACPI notification to the geust
> > OS, that the operator wants to unplug the device.  The guest OS
> > then honours (or not) that by initiating a guest side "eject".
> > IOW disabling guest initiated eject would break device_del too
> > AFAIK.
> 
> That's how it works.
> Sorry if I wasn't able to convey the message in my previous replies.

OK, I just realized I was wrong. The QMP device_del path also checks for
dc->hotpluggable early via qdev_hotplug_unplug_allowed_common() and would 
already abort there. And I can also see the flow that it just triggers ACPI 
and guest eventually completing device eject.
 
So yes, it would disable both guest *and* host side eject.

I already dropped this patch from v2 anyway.

Thanks!

/Christian

[PATCH 1/3] hw/9pfs/virtio: drain in-flight PDUs before virtio-9p unrealize

[Christian Schoenebeck]

A guest can trigger a heap-use-after-free in the virtio transport
unrealize path by submitting a Treaddir request and immediately
ejecting the device via ACPI PCI hotplug. The unrealize path frees
struct LocalData while a worker thread still holds a reference
on it, causing a UAF in local_open_nofollow().

Fix this by draining all in-flight 9p PDUs by calling v9fs_reset()
before final server cleanup. This ensures all coroutines completed,
all FIDs are closed, and no worker thread still holds references
on 9p server state when it is freed.

Reported-by: Jia Jia <physicalmtea@gmail.com>
Suggested-by: Jia Jia <physicalmtea@gmail.com>
Fixes: 6cecf09373 ("virtio-9p-device: add minimal unrealize handler")
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3937
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
---
 hw/9pfs/virtio-9p-device.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index 50dc93091d..1ec48fc9e0 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -243,6 +243,7 @@ static void virtio_9p_device_unrealize(DeviceState *dev)
     V9fsVirtioState *v = VIRTIO_9P(dev);
     V9fsState *s = &v->state;
 
+    v9fs_reset(s);
     virtio_delete_queue(v->vq);
     virtio_cleanup(vdev);
     v9fs_device_unrealize_common(s);
-- 
2.47.3

Re: [PATCH 1/3] hw/9pfs/virtio: drain in-flight PDUs before virtio-9p unrealize

[Christian Schoenebeck]

On Thursday, 9 July 2026 15:50:36 CEST Christian Schoenebeck wrote:
> A guest can trigger a heap-use-after-free in the virtio transport
> unrealize path by submitting a Treaddir request and immediately
> ejecting the device via ACPI PCI hotplug. The unrealize path frees
> struct LocalData while a worker thread still holds a reference
> on it, causing a UAF in local_open_nofollow().
> 
> Fix this by draining all in-flight 9p PDUs by calling v9fs_reset()
> before final server cleanup. This ensures all coroutines completed,
> all FIDs are closed, and no worker thread still holds references
> on 9p server state when it is freed.
> 
> Reported-by: Jia Jia <physicalmtea@gmail.com>
> Suggested-by: Jia Jia <physicalmtea@gmail.com>
> Fixes: 6cecf09373 ("virtio-9p-device: add minimal unrealize handler")
> Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3937
> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
> ---

Jia, if desired, I can make you the official author of this patch. If that's 
what you want, then please reply-to-all to this message with the same email 
address that you used for your report already, and acknowledge that you would 
be fine that I add a:

Signed-off-by: Jia Jia <physicalmtea@gmail.com>

tag on behalf of you, for the reason described here:

https://www.qemu.org/docs/master/devel/submitting-a-patch.html

>  hw/9pfs/virtio-9p-device.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
> index 50dc93091d..1ec48fc9e0 100644
> --- a/hw/9pfs/virtio-9p-device.c
> +++ b/hw/9pfs/virtio-9p-device.c
> @@ -243,6 +243,7 @@ static void virtio_9p_device_unrealize(DeviceState *dev)
> V9fsVirtioState *v = VIRTIO_9P(dev);
>      V9fsState *s = &v->state;
> 
> +    v9fs_reset(s);
>      virtio_delete_queue(v->vq);
>      virtio_cleanup(vdev);
>      v9fs_device_unrealize_common(s);

Re: [PATCH 1/3] hw/9pfs/virtio: drain in-flight PDUs before virtio-9p unrealize

[m'te'a physical]

[-- Attachment #1: Type: text/plain, Size: 2341 bytes --]

 Hi Christian,

 Sure, thanks for handling this.

 Please make me the author of patch 1/3, and feel free to add:

 Signed-off-by: Jia Jia <physicalmtea@gmail.com>

 on my behalf.

 Thanks,
 Jia

Christian Schoenebeck <qemu_oss@crudebyte.com> 于2026年7月9日周四 22:20写道：

> On Thursday, 9 July 2026 15:50:36 CEST Christian Schoenebeck wrote:
> > A guest can trigger a heap-use-after-free in the virtio transport
> > unrealize path by submitting a Treaddir request and immediately
> > ejecting the device via ACPI PCI hotplug. The unrealize path frees
> > struct LocalData while a worker thread still holds a reference
> > on it, causing a UAF in local_open_nofollow().
> >
> > Fix this by draining all in-flight 9p PDUs by calling v9fs_reset()
> > before final server cleanup. This ensures all coroutines completed,
> > all FIDs are closed, and no worker thread still holds references
> > on 9p server state when it is freed.
> >
> > Reported-by: Jia Jia <physicalmtea@gmail.com>
> > Suggested-by: Jia Jia <physicalmtea@gmail.com>
> > Fixes: 6cecf09373 ("virtio-9p-device: add minimal unrealize handler")
> > Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3937
> > Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
> > ---
>
> Jia, if desired, I can make you the official author of this patch. If
> that's
> what you want, then please reply-to-all to this message with the same
> email
> address that you used for your report already, and acknowledge that you
> would
> be fine that I add a:
>
> Signed-off-by: Jia Jia <physicalmtea@gmail.com>
>
> tag on behalf of you, for the reason described here:
>
> https://www.qemu.org/docs/master/devel/submitting-a-patch.html
>
> >  hw/9pfs/virtio-9p-device.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
> > index 50dc93091d..1ec48fc9e0 100644
> > --- a/hw/9pfs/virtio-9p-device.c
> > +++ b/hw/9pfs/virtio-9p-device.c
> > @@ -243,6 +243,7 @@ static void virtio_9p_device_unrealize(DeviceState
> *dev)
> > V9fsVirtioState *v = VIRTIO_9P(dev);
> >      V9fsState *s = &v->state;
> >
> > +    v9fs_reset(s);
> >      virtio_delete_queue(v->vq);
> >      virtio_cleanup(vdev);
> >      v9fs_device_unrealize_common(s);
>
>
>

[-- Attachment #2: Type: text/html, Size: 3425 bytes --]