[PULL 0/2] 9p queue 2026-02-28

[PULL 0/2] 9p queue 2026-02-28

[Christian Schoenebeck]

The following changes since commit d8a9d97317d03190b34498741f98f22e2a9afe3e:

  Merge tag 'pull-target-arm-20260226' of https://gitlab.com/pm215/qemu into staging (2026-02-26 16:00:07 +0000)

are available in the Git repository at:

  https://github.com/cschoenebeck/qemu.git tags/pull-9p-20260228

for you to fetch changes up to b72d15f47cbd2fc93580f33fa86a7e23595a68dd:

  hw/9pfs: fix missing EOPNOTSUPP on Twstat and Trenameat for fs synth driver (2026-02-28 13:46:42 +0100)

----------------------------------------------------------------
9pfs changes:

* Fix crash under unlink-heavy load in v9fs_mark_fids_unreclaim().

* Fix crash with the synth fs driver.

----------------------------------------------------------------
Christian Schoenebeck (1):
      hw/9pfs: fix missing EOPNOTSUPP on Twstat and Trenameat for fs synth driver

Richie Buturla (1):
      hw/9pfs: fix data race in v9fs_mark_fids_unreclaim()

 hw/9pfs/9p.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

[PULL 2/2] hw/9pfs: fix missing EOPNOTSUPP on Twstat and Trenameat for fs synth driver

[Christian Schoenebeck]

Renaming files/dirs is only supported by path-based fs drivers. EOPNOTSUPP
should be returned on any renaming attempt for not path-based fs drivers.
This was already the case for 9p "Trename" request type. However for 9p
request types "Trenameat" and "Twstat" this was yet missing.

So fix this by checking in Twstat and Trenameat request handlers whether
the fs driver in use is really path based, if not return EOPNOTSUPP and
abort further handling of the request.

This fixes a crash with the 9p "synth" fs driver which is not path-based.

The crash happened because the synth driver stores and expects a raw
V9fsSynthNode pointer instead of a C-string on V9fsPath.data. So the
C-string delivered by 9p server to synth fs driver was incorrectly
casted to a V9fsSynthNode pointer, eventually causing a segfault.

Reported-by: Oliver Chang <ochang@google.com>
Fixes: https://issues.oss-fuzz.com/issues/477990727
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3298
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Link: https://lore.kernel.org/qemu-devel/E1vrbaP-000Gqb-B3@kylie.crudebyte.com/
---
 hw/9pfs/9p.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index 02366f43a8..e2713b9eee 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -3516,6 +3516,12 @@ static void coroutine_fn v9fs_renameat(void *opaque)
         goto out_err;
     }
 
+    /* if fs driver is not path based, return EOPNOTSUPP */
+    if (!(s->ctx.export_flags & V9FS_PATHNAME_FSCONTEXT)) {
+        err = -EOPNOTSUPP;
+        goto out_err;
+    }
+
     v9fs_path_write_lock(s);
     err = v9fs_complete_renameat(pdu, olddirfid,
                                  &old_name, newdirfid, &new_name);
@@ -3606,6 +3612,11 @@ static void coroutine_fn v9fs_wstat(void *opaque)
         }
     }
     if (v9stat.name.size != 0) {
+        /* if fs driver is not path based, return EOPNOTSUPP */
+        if (!(s->ctx.export_flags & V9FS_PATHNAME_FSCONTEXT)) {
+            err = -EOPNOTSUPP;
+            goto out;
+        }
         v9fs_path_write_lock(s);
         err = v9fs_complete_rename(pdu, fidp, -1, &v9stat.name);
         v9fs_path_unlock(s);
-- 
2.47.3

[PULL 1/2] hw/9pfs: fix data race in v9fs_mark_fids_unreclaim()

[Christian Schoenebeck]

From: Richie Buturla <richie@linux.ibm.com>

A data race between v9fs_mark_fids_unreclaim() and v9fs_path_copy()
causes an inconsistent read of fidp->path. In v9fs_path_copy(), the
path size is set before the data pointer is allocated, creating a
window where size is non-zero but data is NULL.

v9fs_co_open2() holds a write lock during path modifications,
but v9fs_mark_fids_unreclaim() was not acquiring a read
lock, allowing it to race.

Fix by holding the path read lock during FID table iteration.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3300
Signed-off-by: Richie Buturla <richie@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260211154450.254338-1-richie@linux.ibm.com/
Fixes: 7a46274529 ("hw/9pfs: Add file descriptor reclaim support")
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
---
 hw/9pfs/9p.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index 6fbe604ce8..02366f43a8 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -560,6 +560,7 @@ static int coroutine_fn v9fs_mark_fids_unreclaim(V9fsPDU *pdu, V9fsPath *path)
             sizeof(V9fsFidState *), 1);
     gint i;
 
+    v9fs_path_read_lock(s);
     g_hash_table_iter_init(&iter, s->fids);
 
     /*
@@ -580,6 +581,7 @@ static int coroutine_fn v9fs_mark_fids_unreclaim(V9fsPDU *pdu, V9fsPath *path)
             g_array_append_val(to_reopen, fidp);
         }
     }
+    v9fs_path_unlock(s);
 
     for (i = 0; i < to_reopen->len; i++) {
         fidp = g_array_index(to_reopen, V9fsFidState*, i);
-- 
2.47.3

Re: [PULL 0/2] 9p queue 2026-02-28

[Michael Tokarev]

On 28.02.2026 16:30, Christian Schoenebeck wrote:

> 9pfs changes:
> * Fix crash under unlink-heavy load in v9fs_mark_fids_unreclaim().
> * Fix crash with the synth fs driver.
> 
> ----------------------------------------------------------------
> Christian Schoenebeck (1):
>        hw/9pfs: fix missing EOPNOTSUPP on Twstat and Trenameat for fs synth driver
> 
> Richie Buturla (1):
>        hw/9pfs: fix data race in v9fs_mark_fids_unreclaim()

Hi!

I'm picking these changes up for active qemu stable releases,
as these looks like bug fixes worth to have.

Please let me know if I shouldn't do that.

Also, please Cc: qemu-stable for future patches which, in your
opinion, should be back-ported to the stable releases.

Thanks,

/mjt

Re: [PULL 0/2] 9p queue 2026-02-28

[Peter Maydell]

On Sat, 28 Feb 2026 at 13:33, Christian Schoenebeck
<qemu_oss@crudebyte.com> wrote:
>
> The following changes since commit d8a9d97317d03190b34498741f98f22e2a9afe3e:
>
>   Merge tag 'pull-target-arm-20260226' of https://gitlab.com/pm215/qemu into staging (2026-02-26 16:00:07 +0000)
>
> are available in the Git repository at:
>
>   https://github.com/cschoenebeck/qemu.git tags/pull-9p-20260228
>
> for you to fetch changes up to b72d15f47cbd2fc93580f33fa86a7e23595a68dd:
>
>   hw/9pfs: fix missing EOPNOTSUPP on Twstat and Trenameat for fs synth driver (2026-02-28 13:46:42 +0100)
>
> ----------------------------------------------------------------
> 9pfs changes:
>
> * Fix crash under unlink-heavy load in v9fs_mark_fids_unreclaim().
>
> * Fix crash with the synth fs driver.
>
> ----------------------------------------------------------------
> Christian Schoenebeck (1):
>       hw/9pfs: fix missing EOPNOTSUPP on Twstat and Trenameat for fs synth driver
>
> Richie Buturla (1):
>       hw/9pfs: fix data race in v9fs_mark_fids_unreclaim()



Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/11.0
for any user-visible changes.

-- PMM

Re: [PULL 0/2] 9p queue 2026-02-28

[Christian Schoenebeck]

On Sunday, 1 March 2026 07:23:43 CET Michael Tokarev wrote:
> On 28.02.2026 16:30, Christian Schoenebeck wrote:
> > 9pfs changes:
> > * Fix crash under unlink-heavy load in v9fs_mark_fids_unreclaim().
> > * Fix crash with the synth fs driver.
> > 
> > ----------------------------------------------------------------
> > 
> > Christian Schoenebeck (1):
> >        hw/9pfs: fix missing EOPNOTSUPP on Twstat and Trenameat for fs
> >        synth driver
> > 
> > Richie Buturla (1):
> >        hw/9pfs: fix data race in v9fs_mark_fids_unreclaim()
> 
> Hi!
> 
> I'm picking these changes up for active qemu stable releases,
> as these looks like bug fixes worth to have.

Yes, that makes sense.

> Please let me know if I shouldn't do that.
> 
> Also, please Cc: qemu-stable for future patches which, in your
> opinion, should be back-ported to the stable releases.

I usually do. For some reason I have forgotten to CC qemu-stable this time. 
Thanks for the reminder and noticing!

/Christian