CVE CyberSecurity Database News

CVE-2023-2861 - Breaking Out of the QEMU 9pfs Jail – How One Flaw Threatens Virtual Machines

Poster -

---

Introduction

Virtual machines (VMs) and containers often rely on sharing filesystems securely between the guest and the host. QEMU's 9pfs ("Plan 9 Filesystem") lets virtual machines exchange files with the host system, offering a shared folder just like those in VirtualBox or VMware. A shocking flaw, CVE-2023-2861, discovered in 2023, broke that trust wide open.

In this article, we'll walk through how this vulnerability worked, including easy-to-understand code snippets, proof-of-concept explanations, and remediation steps. This article is written for technologists of all backgrounds, not just security pros.

What Is 9pfs in QEMU?

QEMU is a popular open-source VM emulator. The 9p passthrough filesystem, or 9pfs, lets a guest VM access a directory on the host. You set it up in your QEMU launch command like so:

qemu-system-x86_64 \
  -fsdev local,id=fsdev,path=/host/shared-folder,security_model=none \
  -device virtio-9p-pci,fsdev=fsdev,mount_tag=hostshare

Then, inside the guest, you mount it

mount -t 9p -o trans=virtio hostshare /mnt/hostshare

From here, files in /host/shared-folder (on the host) are accessible by the guest via /mnt/hostshare (inside the VM). It's meant to be simple and safe.

What's the Problem? (The Vulnerability Explained)

A good security design should prevent VMs from accessing *any* files except those explicitly shared. However, CVE-2023-2861 occurred because the 9pfs code in QEMU didn't prevent special files from being opened inside the shared directory.

That means a guest user could create a *device file* (like /dev/mem, /dev/sda, /dev/zero, etc.) inside the shared folder, then open it through 9pfs. On the host, this request was not blocked or filtered, so QEMU would actually open the real host-side device - potentially allowing the VM to read or write to host devices.

Example scenario

- Malicious user inside the VM creates a special device file in /mnt/hostshare.
- Opens this file and attempts to interact with underlying host hardware (e.g., read from /dev/mem).
- If permitted, this could lead to VM escape, arbitrary host code execution, or reading sensitive host data.

Let's imagine a malicious client inside your VM runs

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

int main() {
    // Create a character device node inside the shared folder.
    // Let's say major=1, minor=1 maps to /dev/mem on the host.
    mknod("/mnt/hostshare/fake_mem", S_IFCHR | 0666, makedev(1,1));

    // Now open it: The request travels through 9pfs to the host!
    int fd = open("/mnt/hostshare/fake_mem", O_RDONLY);
    if (fd >= ) {
        // Potentially reading host memory...!
        char buf[128];
        read(fd, buf, sizeof(buf));
        // Do something malicious.
        close(fd);
    }
    return ;
}

What happens here:
The mknod call makes a device special file in the 9p share. The subsequent open triggers QEMU into opening the *host*'s /dev/mem, not just a harmless file! This bypasses almost all the intended boundaries between the VM and physical hardware.

Attackers can read from or write to host devices.

- Possible escalation from VM user -> root on host (by, say, writing to /dev/mem, /dev/kmem, or /dev/sda).

Compromise of all data on the host, or pivoting into the broader infrastructure.

Who is vulnerable?
Anyone with QEMU VMs using the 9pfs feature and “security_model=none” (the default in many tutorials/examples). More restrictive security models do mitigate some risk, but not all.

References and In-Depth Resources

- CVE-2023-2861 at NVD
- QEMU Security Notices
- Red Hat Security Bulletin
- Upstream Patch Commit

QEMU maintainers quickly patched 9pfs

- 9pfs no longer allows opening special files (block or char devices, pipes, etc.) within the shared folder.

Patch summary (simplified)

stat(path, &st);
if (S_ISCHR(st.st_mode) || S_ISBLK(st.st_mode)) {
    // Deny access to these files.
    return -EPERM;
}

Update QEMU as soon as possible to a version including this commit (or newer).

Avoid security_model=none: Use security_model=mapped-xattr or mapped-file.

3. Restrict Shared Folders: Don’t share sensitive directories (like /, /dev, /etc).
4. Use VM Isolation: 9pfs is for *trusted* workloads only – for untrusted code, use stronger sandboxing (e.g., gVisor, Firecracker).
5. Monitor for Suspicious Activity: Watch for unexpected device node creation in shared folders, or odd file opens.

Conclusion

CVE-2023-2861 reminds us that even simple file sharing between host and guest is never truly simple. Always stay updated, and treat shared filesystems as privileged attack surfaces. Security is an ever-shifting landscape – this time, thankfully, a prompt fix arrived before serious damage was done.

Stay safe and keep your hypervisors updated!

*This article is original content created for clarity and education. For sharing and reference, please cite this permalink: [QEMU 9pfs CVE-2023-2861 Deep Dive](#).*

Timeline

Published on: 12/06/2023 07:15:41 UTC
Last modified on: 12/11/2023 17:44:27 UTC