Re: [PATCH] hw/9pfs: mutate FID path from main thread only (CVE-2026-93834)

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Sep 22, 2026 at 08:13:01AM +0200, Greg Kurz wrote:
> On Mon, 21 Sep 2026 14:18:58 +0200
> Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> 
> > v9fs_co_open2() is the only code that mutates a FID path from a worker
> > thread: inside its v9fs_co_run_in_worker() block it frees fidp->path
> > and copies in the new path under the held FID path write lock.
> > 
> > Every other FID path mutation in the 9p codebase happens on the main
> > thread, so main thread readers (v9fs_walk(), v9fs_xattrwalk(),
> > v9fs_stat(), v9fs_co_name_to_path()) rely on the same (main) thread
> > atomicity and don't take the path read lock themselves on main thread.
> > 
> > Fix this by making the worker thread block in v9fs_co_open2() read-only
> > with respect to the FID: render the new path into the local 'path'
> > variable only and copy it to fidp->path after the worker block returned
> > back to the main thread and still under the held write lock of the FID,
> > like every other FID path mutation does.
> > 
> > Fixes: 02cb7f3a25 ("hw/9pfs: Use read-write lock for protecting fid path.")
> 
> Wow, it's a long standing issue ! ;-)
> 
> > Fixes: CVE-2026-93834
> 
> Cannot find it... embargoed ?
> 
> > Reported-by: Milad Nasr <https://gitlab.com/sirkhezr>
> > Suggested-by: Milad Nasr <https://gitlab.com/sirkhezr>
> > Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4491
> 
> Cannot find that either...

Initially confidential, so only visible to maintainers with acccounts
added to the gitlab project. Bugs should be made public when their
patch is posted for review, so I've turned off the confidential flag
now.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|