CVE-2026-93834 — QEMU 9pfs fid path UAF guest escape

Summary

QEMU’s 9pfs is the host half of virtio-9p, also called VirtFS: it serves a host directory to a guest over the 9P2000.L protocol. The guest kernel mounts the share as a 9p filesystem, every file operation in the guest becomes a 9P request, and QEMU carries out the request on the host on the guest’s behalf, confined to the exported directory. For each file or directory the guest has open, QEMU keeps a fid holding the host path it refers to.

QEMU runs the actual filesystem calls on worker threads and does the request bookkeeping on its main thread. v9fs_co_open2() — the handler behind Tlcreate, which creates and opens a file — was the only code that changed a fid’s path from a worker thread: it freed the old path and copied in the new one while holding the fid-path write lock. The code that reads fid paths on the main thread (v9fs_walk() for Twalk, v9fs_xattrwalk(), v9fs_stat(), v9fs_co_name_to_path()) takes no read lock, because every other path change happens on the main thread too. A guest that sends Tlcreate and Twalk requests concurrently can therefore make a walk copy a path that has just been freed, or is only half written.

The reporter turned that into a directory escape. The copied path holds stale heap data with no terminating NUL inside its recorded length, and the host-side open in hw/9pfs/9p-local.c then resolves it to a location outside the exported directory. From there the guest reads and writes arbitrary host files with the privileges of the QEMU process, and can run code as that user — an escape from the virtual machine. In the upstream issue it succeeded in 4 of 5 runs against Debian’s 10.0.13 build and 11 of 11 against master, and was also reproduced on Debian’s 7.2.22 build; with the fix applied there were no escapes in 9 runs of about 24,000 race rounds.

The attacker needs root inside the guest, or whatever rights the guest grants to mount and use the 9p share, which is what the CVSS vector’s AV:L/PR:L records. On a host that runs VMs for other people, the guest’s root user is the tenant.

ℹ️ Exposure follows configuration. Only a VM with a 9p share is exposed: QEMU’s -virtfs option, -fsdev plus a virtio-9p device, or a libvirt <filesystem type='mount'> using the default path driver. virtio-fs (virtiofsd) shares do not use this code. Where a 9p share exists, only a QEMU build carrying the upstream fix closes the bug — and a running VM keeps the QEMU binary it was started with until it is stopped and started again.

Affected versions

The racing reader became unlocked in QEMU 6.1.0, which is where the reporter places the practical window; Red Hat marks its QEMU builds older than that — the qemu-kvm of RHEL 6 and 7 — not affected. Debian’s tracker records the bug as introduced with 02cb7f3a25 in v1.0-rc0. Either way, every QEMU tracked below is inside the window.

For operators building from source, the fix is a single-file patch to hw/9pfs/cofile.c (mailing-list post); on a stable branch older than 11.0, check that it applies cleanly, since the file has changed since then.

Patch status

A row is Fixed once its QEMU carries the upstream fix — a release that contains fe9e30899f, or a distribution package with the patch backported. Distributions routinely backport onto older QEMU versions, so an old version string does not by itself mean vulnerable, and a new one does not by itself mean fixed.

Current version is what the release ships today; First fixed is the first build that carried the fix, and Fixed since the date it became available. Debian versions are the apt-installable value: the <suite>-security archive where it is ahead of the main archive.

QEMU

The fix makes the worker-thread part of v9fs_co_open2() read-only with respect to the fid: it builds the new path in a local variable and copies it into the fid only after control has returned to the main thread, still under the fid-path write lock — the way every other fid path change already worked. It was written by Christian Schoenebeck, the 9pfs maintainer, reviewed by Greg Kurz, and merged to master on 2026-09-23 with the pull-9p-20260923 pull request.

QEMU’s stable branches get fixes as cherry-picks, which the stable maintainers queue on a staging-X.Y branch before tagging the next point release. The maintained series are 11.1, 11.0, and the 10.0 long-term branch; the backport has now reached a tagged point release on all three.

Older series are no longer maintained upstream and will not get a fixed release: 10.2 ended with 10.2.4 (2026-06-25), 10.1 with 10.1.5 (2026-03-17), 9.2 with 9.2.4 (2025-05-26), and 7.2 with 7.2.22 (2025-12-05). A distribution that still ships one of them — NixOS 26.05 (10.2), Debian bookworm and pkgsrc’s emulators/qemu7 (7.2) — has to carry the patch itself. Red Hat’s QEMU builds follow their own backport stream and are covered under Rocky Linux below.

To check a source tree directly: in a fixed tree, v9fs_co_open2() in hw/9pfs/cofile.c no longer calls v9fs_path_copy() on fidp->path inside its v9fs_co_run_in_worker() block.

Debian

The Debian security tracker is the authoritative source for per-suite status: sid and forky carry the fix, through sid’s fixed upload migrating into testing, while trixie and bookworm remain vulnerable with no DSA or DLA yet. The virtual machine emulators are the qemu-system-* binary packages built from the qemu source.

Debian’s security team has classified trixie’s case <no-dsa> (Minor issue): no dedicated advisory is planned, so trixie’s fix depends on the next stable point release carrying a 10.0.x backport upstream. Bookworm’s 7.2 series is finished upstream, so its fix has to come as a Debian backport in a security upload.

Proxmox VE

Proxmox VE ships its own QEMU build, pve-qemu-kvm, in its own repositories rather than Debian’s qemu. Proxmox’s packaging carries security fixes as patches on top of the upstream release, so a fixed pve-qemu-kvm may well keep its upstream version and bump only the packaging revision.

A default Proxmox VE guest has no 9p share. Proxmox VE’s built-in directory sharing (the virtiofs VM option, added in 8.4) uses virtiofsd, not 9p; a VM gets a 9p share only if someone added a -virtfs or -fsdev option to its args: line by hand.

Proxmox VE 8 reached end of life in August 2026. Its last QEMU build, pve-qemu-kvm 9.2.0-8 of 2026-08-07, is vulnerable and no fix is coming — a host still on Proxmox VE 8 that runs guests with 9p shares should upgrade to Proxmox VE 9, or remove the shares.

pkgsrc

The pkgsrc tree (NetBSD’s package collection, also used on SmartOS, macOS via pkgin, and elsewhere) ships QEMU twice: emulators/qemu tracks the current upstream release, and emulators/qemu7 keeps the 7.2 series, which upstream stopped maintaining after 7.2.22.

A fix for emulators/qemu7 can only arrive as a patch in the package’s patches/ directory; pkgsrc-current’s emulators/qemu picked up the fix through its regular upstream version bump, with no patch needed. pkgsrc-2026Q3, the current quarterly branch, receives fixes by pull-up from pkgsrc-current and has not yet picked this one up.

The identifier carries an nbN suffix when the package’s PKGREVISION is set. That revision bumps for many reasons besides security patches — recursive bumps for shared-library ABI changes, dependency and build-system tweaks — so an nbN suffix on its own says nothing about this CVE.

NixOS

nixpkgs builds QEMU from a single expression, pkgs/by-name/qe/qemu/package.nix; qemu_kvm, qemu_full, and qemu-utils are overrides of the same expression, so one row per channel covers every variant. A channel is fixed once its pinned version carries the fix or the expression carries the upstream patch.

On the unstable side the fix arrives with QEMU 11.1.2, the first fixed 11.1 release; no nixpkgs patch is involved. NixOS 26.05 is on the 10.2 series, which upstream no longer maintains, so its fix has to come either as a patch in nixpkgs or as a move to a maintained series.

The NixOS qemu-vm module — behind nixos-rebuild build-vm and the NixOS test driver’s VMs — shares host directories, including the host’s /nix/store, with the guest. On NixOS 26.05 it does so over 9p. On nixpkgs master it uses virtio-fs on Linux hosts and keeps 9p only on Darwin hosts. Those VMs run the configuration you gave them, so the risk is a compromised guest rather than a hostile tenant — but it is a 9p share all the same.

A channel row’s Fixed since is the date that channel published its first release containing the fix; a branch row’s is the date the fix was merged into that branch.

Flake users

A flake input like github:NixOS/nixpkgs/nixos-unstable resolves to the git branch of that name, not to the channel — but the channel bot advances the branch to exactly the revision the channel publishes, so an input following a channel name is answered by that channel’s row.

Two branches have no channel gating them and will carry the fix earlier — they are listed above as master and release-26.05:

• github:NixOS/nixpkgs/master — the fix’s first appearance anywhere in nixpkgs, the moment it is merged.
• github:NixOS/nixpkgs/release-26.05 — the ungated 26.05 branch, ahead of the nixos-26.05 channel by however long Hydra takes.

Their Fixed since will be the commit date of the fixing commit, not a channel release date: an ungated branch has the fix as soon as the commit lands. That also bounds every other row — no channel can be fixed before the branch it is cut from.

Rocky Linux and RHEL

Rocky Linux rebuilds RHEL, so it cannot ship a fix before Red Hat does. Red Hat lists qemu-kvm in RHEL 10 and 9, and the virt:rhel module’s qemu-kvm in RHEL 8, as affected, with no fixed release yet. The package lives in the AppStream repository. Red Hat marks the much older qemu-kvm of RHEL 7 and 6 not affected.

Red Hat’s own mitigation is not to configure 9pfs/VirtFS sharing (-fsdev, -virtfs), and to use virtio-fs instead where host–guest file sharing is needed.

Detection

A host is exposed only while it runs a VM with a 9p share. To list running QEMU processes whose command line sets one up:

pgrep -af 'virtfs|fsdev|virtio-9p'

No output means no running VM uses 9p. For libvirt-managed guests, look at each domain’s <filesystem> elements; one with no <driver> element, or with a driver type other than virtiofs, is a 9p share:

virsh dumpxml <domain> | grep -A3 '<filesystem'

On Proxmox VE, a 9p share can only come from a VM’s args: line. This lists the VM configurations that have one:

grep -lE 'virtfs|fsdev' /etc/pve/qemu-server/*.conf

From inside a Linux guest, a 9p mount shows up as filesystem type 9p:

mount -t 9p

Is the installed QEMU fixed?

Upstream QEMU reports its version with:

qemu-system-x86_64 --version

• 11.2.0 or later ⇒ fixed.
• Anything older ⇒ vulnerable, unless the distribution packager has backported the fix (see the per-distribution notes above), or a stable release carrying it appears in the QEMU rows of Patch status.

A distribution backport keeps the upstream version and changes the packaging revision, so query the package manager rather than the binary. On Debian:

dpkg-query -W 'qemu-system-*'

On Proxmox VE:

dpkg-query -W pve-qemu-kvm

On Rocky Linux:

rpm -q qemu-kvm

On pkgsrc (both emulators/qemu and emulators/qemu7 install as qemu):

pkg_info -e qemu

Cross-reference the result against the matching rows in Patch status. On NixOS, the QEMU in a system closure is the version = in pkgs/by-name/qe/qemu/package.nix at the channel revision the system was built from; compare against the channel’s row.

Running VMs keep the old QEMU

Installing a fixed package does not fix a VM that is already running: the guest keeps the QEMU process it was started with, and a reboot from inside the guest does not replace it. Each VM with a 9p share needs a full stop and start, or a live migration to a host running the fixed build. On Proxmox VE, the QEMU version a VM is actually running shows as running-qemu:

qm status <vmid> --verbose | grep running-qemu

which prints, for example, running-qemu: 11.0.3.

Mitigation

There is no configuration switch inside 9pfs that closes the race: the bug is in how QEMU updates a fid’s path, and only a build carrying the upstream fix removes it. Upgrade as soon as your distribution ships one, or apply the upstream patch to a source build.

Until then:

• Remove 9p shares, or move them to virtio-fs. This is Red Hat’s stated mitigation: do not configure -fsdev or -virtfs, and use virtiofsd where the guest needs host files. A VM with no 9p share cannot reach the vulnerable code. Remember that the change takes effect only once the VM has been stopped and started again.
• Keep QEMU confined. The escape runs as the QEMU process user. libvirt’s per-VM sVirt labelling (SELinux or AppArmor) and running QEMU as an unprivileged user limit what an escaped guest can reach on the host. That narrows the damage; it does not fix the bug.
• Decide who is root in the guest. Triggering the race needs root, or 9p mount rights, inside the guest. On hosts where the guests belong to other people, assume they have it.

A reproducer is described in the public upstream issue, and CISA’s SSVC assessment records exploitation as poc. The bug is not in CISA’s Known Exploited Vulnerabilities catalog.

Verification log

Every verdict in the table above is backed by a checkable source. This log records the provenance — the advisory, repository index, or git reference that established each fact — so any row can be audited or reproduced. Most readers never need it.

References