9p: write lock path in v9fs_co_open2()
commit5b76ef50f62079a2389ba28cacaf6cce68b1a0ed
authorGreg Kurz <groug@kaod.org>
Wed, 7 Nov 2018 00:00:04 +0000 (7 01:00 +0100)
committerGreg Kurz <groug@kaod.org>
Thu, 8 Nov 2018 20:19:05 +0000 (8 21:19 +0100)
tree96d84008da66d9464e1799b7af71fa13111fa6e2
parenta7ce790a029bd94eb320d8c69f38900f5233997e
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>
hw/9pfs/cofile.c