[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [PATCH] 9p: write lock path in v9fs_co_open2()

From: Greg Kurz
Subject: [Qemu-devel] [PATCH] 9p: write lock path in v9fs_co_open2()
Date: Wed, 07 Nov 2018 01:21:18 +0100
User-agent: StGit/unknown-version

The assumption that the fid cannot be used by any other operation is
wrong. At least, nothing prevents a misbehaving client to create a
file with a given fid, and to pass this fid to some other operation
at the same time (ie, without waiting for the response to the creation
request). The call to v9fs_path_copy() performed by the worker thread
after the file was created can race with any access to the fid path
performed by some other thread. This causes use-after-free issues that
can be detected by ASAN with a custom 9p client.

Unlike other operations that only read the fid path, v9fs_co_open2()
does modify it. It should hence take the write lock.

Cc: P J P <address@hidden>
Reported-by: zhibin hu <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>
 hw/9pfs/cofile.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/9pfs/cofile.c b/hw/9pfs/cofile.c
index 88791bc327ac..9c22837cda32 100644
--- a/hw/9pfs/cofile.c
+++ b/hw/9pfs/cofile.c
@@ -140,10 +140,10 @@ int coroutine_fn v9fs_co_open2(V9fsPDU *pdu, V9fsFidState 
     cred.fc_gid = gid;
      * Hold the directory fid lock so that directory path name
-     * don't change. Read lock is fine because this fid cannot
-     * be used by any other operation.
+     * don't change. Take the write lock to be sure this fid
+     * cannot be used by another operation.
-    v9fs_path_read_lock(s);
+    v9fs_path_write_lock(s);
             err = s->ops->open2(&s->ctx, &fidp->path,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]