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

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

On Tuesday, 22 September 2026 14:30:53 CEST Daniel P. Berrangé wrote:
> 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.

Strange policies. I would have:

- Added Greg (reviewer and previous 9p maintainer for years) to the report 
while it was still private. Instead I am the only one getting LLM generated 
security reports thrown at me.

- Considering the severeness of the vulnerability, I would have waited for the 
patch been pushed through stable branches before making the full report 
public, or at least until merged on git.

/Christian