Commit 5b76ef50 authored by Greg Kurz's avatar Greg Kurz
Browse files

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: default avatarzhibin hu <noirfate@gmail.com>
Signed-off-by: default avatarGreg Kurz <groug@kaod.org>
parent a7ce790a

hw/9pfs/cofile.c

+3 −3
Original line number Diff line number Diff line
@@ -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,