On Wednesday, 20 May 2026 19:11:25 CEST Christian Schoenebeck wrote: > From: sin99xx <[email protected]> > > v9fs_co_readdir_many() dispatches do_readdir_many() to a worker thread > that reads V9fsFidState's path.data without holding a rename lock. > > A concurrent rename request, e.g. of its parent dir, causes the FID's > absolute path to be altered by freeing the old path string and > assigning a new one. This causes a heap-use-after-free race condition > while do_readdir_many() is still accessing the old object. > > This allows a DoS by an unprivileged guest user. > > Fix this by wrapping the worker thread dispatch block within a pair of > v9fs_path_read_lock() and v9fs_path_unlock() calls, like it's done at > other places. > > Fixes: 2149675b195f ("9pfs: add new function v9fs_co_readdir_many()") > Fixes: CVE-2026-48004 > Reported-by: sin99xx <[email protected]> > [Christian Schoenebeck: add commit log message] > Signed-off-by: Christian Schoenebeck <[email protected]> > ---
With updated author's email address, queued on 9p.next: https://github.com/cschoenebeck/qemu/commits/9p.next Thanks! /Christian
