aboutsummaryrefslogtreecommitdiff
path: root/hw/9pfs
diff options
context:
space:
mode:
authorGreg Kurz <groug@kaod.org>2018-11-07 01:00:04 +0100
committerGreg Kurz <groug@kaod.org>2018-11-08 21:19:05 +0100
commit5b76ef50f62079a2389ba28cacaf6cce68b1a0ed (patch)
tree96d84008da66d9464e1799b7af71fa13111fa6e2 /hw/9pfs
parenta7ce790a029bd94eb320d8c69f38900f5233997e (diff)
9p: write lock path in v9fs_co_open2()
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 <ppandit@redhat.com> Reported-by: zhibin hu <noirfate@gmail.com> Signed-off-by: Greg Kurz <groug@kaod.org>
Diffstat (limited to 'hw/9pfs')
-rw-r--r--hw/9pfs/cofile.c6
1 files changed, 3 insertions, 3 deletions
diff --git a/hw/9pfs/cofile.c b/hw/9pfs/cofile.c
index 88791bc327..9c22837cda 100644
--- a/hw/9pfs/cofile.c
+++ b/hw/9pfs/cofile.c
@@ -140,10 +140,10 @@ int coroutine_fn v9fs_co_open2(V9fsPDU *pdu, V9fsFidState *fidp,
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);
v9fs_co_run_in_worker(
{
err = s->ops->open2(&s->ctx, &fidp->path,