[PATCH] hw/9pfs: fix data race in v9fs_mark_fids_unreclaim()

Richie Buturla posted 1 patch 1 month, 4 weeks ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20260211154450.254338-1-richie@linux.ibm.com
Maintainers: Christian Schoenebeck <qemu_oss@crudebyte.com>, Greg Kurz <groug@kaod.org>
hw/9pfs/9p.c | 2 ++
1 file changed, 2 insertions(+)
[PATCH] hw/9pfs: fix data race in v9fs_mark_fids_unreclaim()
Posted by Richie Buturla 1 month, 4 weeks ago
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>
---
 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.51.0
Re: [PATCH] hw/9pfs: fix data race in v9fs_mark_fids_unreclaim()
Posted by Christian Schoenebeck 1 month, 4 weeks ago
On Wednesday, 11 February 2026 16:44:50 CET Richie Buturla wrote:
> 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>

Another true survivor:
Fixes: 7a46274529 ("hw/9pfs: Add file descriptor reclaim support")

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

Queued on 9p.next:
https://github.com/cschoenebeck/qemu/commits/9p.next

Thanks!

/Christian