From 5b76ef50f62079a2389ba28cacaf6cce68b1a0ed Mon Sep 17 00:00:00 2001 From: Greg Kurz Date: Wed, 7 Nov 2018 01:00:04 +0100 Subject: [PATCH] 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 Reported-by: zhibin hu Signed-off-by: Greg Kurz Upstream-status: Backport Affects: < 3.1.0 CVE: CVE-2018-19364 patch #1 Signed-off-by: Armin Kuster --- 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 88791bc..9c22837 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, -- 2.7.4