mirror of
https://github.com/xemu-project/xemu.git
synced 2024-11-30 23:10:38 +00:00
5b76ef50f6
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> |
||
|---|---|---|
| .. | ||
| 9p-handle.c | ||
| 9p-local.c | ||
| 9p-local.h | ||
| 9p-posix-acl.c | ||
| 9p-proxy.c | ||
| 9p-proxy.h | ||
| 9p-synth.c | ||
| 9p-synth.h | ||
| 9p-util.c | ||
| 9p-util.h | ||
| 9p-xattr-user.c | ||
| 9p-xattr.c | ||
| 9p-xattr.h | ||
| 9p.c | ||
| 9p.h | ||
| codir.c | ||
| cofile.c | ||
| cofs.c | ||
| coth.c | ||
| coth.h | ||
| coxattr.c | ||
| Makefile.objs | ||
| trace-events | ||
| virtio-9p-device.c | ||
| virtio-9p.h | ||
| xen-9p-backend.c | ||
| xen-9pfs.h | ||