GPU VulnDB

Database/Kernel, userspace & hypervisor

QEMU 9pfs: use-after-free race between Tlcreate and Twalk lets a guest escape the shared directory to host files

CVSS 8.8CVE-2026-93834Kernel, userspace & hypervisorcurated

Impact

A race between the QEMU main thread and a 9pfs worker thread on concurrent Tlcreate and Twalk requests lets a malicious guest user craft a fid path built from stale heap data. That bypasses the directory-traversal restrictions and escapes the shared directory boundary, giving arbitrary read and write of host files and code execution as the QEMU process user - a VM escape. On a GPU cloud that hands out VMs with a 9p share for datasets, model caches or agent workspaces, this puts one tenant on the hypervisor host alongside every other tenant's VM on that node, and remediating means restarting QEMU, so every guest on the node has to be migrated or stopped. Red Hat ships the affected QEMU across RHEL 6 through 10, RHEL for NVIDIA 26 and OpenShift Container Platform 4.

Who can reach it

A local user inside a guest VM whose configuration exposes a virtio-9p/9pfs share from the host. No host access needed. Hosts that do not configure 9p passthrough for any guest are not exposed.

What to do

Apply the QEMU update from your vendor when it ships - Red Hat tracks it at access.redhat.com/security/cve/CVE-2026-93834 and bugzilla 2537939; the upstream work item is qemu-project/qemu#4491, and no fixed version is stated in the record. Applying it means restarting the QEMU process, so live-migrate or drain each guest off the host. As a mitigation available now, remove 9pfs/virtio-9p shares from guest configurations; there is no in-place toggle that fixes the race.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.