From: Richie Buturla <[email protected]> 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 <[email protected]> Link: https://lore.kernel.org/qemu-devel/[email protected]/ Fixes: 7a46274529 ("hw/9pfs: Add file descriptor reclaim support") Signed-off-by: Christian Schoenebeck <[email protected]> --- 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
