I have found a number of security vulnerabilities in QEMU using a new LLM scaffold we're building. I'm attaching the worst of these bugs below, but assuming findings like this are interesting to you, I'm curious how you'd like to handle triage of another hundred or so LLM-found-and-as-of-yet-unverified bugs. Most are much less serious than this one (there are several use-after-frees reachable when a guest unplugs its own devices, an out-of-bounds write in the VGA renderer after a virtio-gpu reset, guest-triggerable crashes and hangs in AHCI, HPET and e1000e on the default machine types, etc). What we think is the worst bug is one where root inside a guest with a virtio-9p shared folder can escape that folder: it can read and write any host file the QEMU process can reach, and run commands on the host as the QEMU user. I've attached a reproducer that should demo this. The cause is a race on a fid's path. v9fs_co_open2() (hw/9pfs/cofile.c:168) replaces fidp-\>path on a worker thread, while v9fs_xattrwalk() (hw/9pfs/9p.c:4073) and v9fs_walk() (9p.c:1980) copy the same path on the main thread without taking the path lock. If the main thread reads the old length before the worker frees the buffer, and copies the bytes after the worker has reused that buffer for the new, shorter path, the new fid ends up with a path that has no NUL inside its length. Every later copy carries the stale tail along, and the guest can fill that tail with "../../../../..". local_open_nofollow() (hw/9pfs/9p-local.c:61) resolves the result one openat() at a time and does not reject "..", so a walk from that fid lands above the export, at the host's "/".  The reproducer runs as root in an ordinary Linux guest and drives its own virtio-9p device from userspace. Every request it sends is well-formed; only their timing is hostile. It grooms the heap so the freed buffer is reused, races Tlcreate against bursts of Txattrwalk on the same directory until a walk escapes (a few seconds on our host), and walks to "/". From there it reads /etc/passwd and files owned by the QEMU user, and creates a file in /tmp. It then finds its own QEMU process in /proc, reads that process's maps and the host's libc through the share, writes a short stub over fstatfs64() through /proc//mem, and sends one Tstatfs, which makes QEMU call system(). Finally it restores the original bytes. No address or offset is supplied from outside the guest. When the race goes the other way, QEMU segfaults instead; that happened in 1 of 5 runs on Debian 13 and 3 of 5 on Debian 12. I've attached a zip with an LLM-written report, reproducer, patch, and a screen recording in case you find these helpful. With the patch applied to master, the reproducer no longer reaches anything outside the share. I'd also be happy to get on a call or otherwise discuss this in whatever way is most useful. --- ## Host environment - Operating system: Debian GNU/Linux 13 (trixie) userland (QEMU package and its libraries), running in a container on a Debian GNU/Linux 12 (bookworm) host - OS/kernel version: Linux 6.1.0-51-cloud-amd64 (Debian 6.1.177-1) - Architecture: x86_64 (Intel Xeon 6985P-C), KVM - QEMU flavor: qemu-system-x86_64 - QEMU version: 10.0.13 (Debian 1:10.0.13+ds-0+deb13u1). Also reproduced on 7.2.22 (Debian 1:7.2+dfsg-7+deb12u18+b3) and on git master 28e7aad522 (v11.1.0-1513-g28e7aad522). - QEMU command line (run as an unprivileged user, uid 2001, not root): ``` ./qemu-system-x86_64 -M pc -accel kvm -cpu host -m 2G -nodefaults -display none \ -kernel vmlinuz -initrd initramfs.gz \ -append 'console=ttyS0 quiet memmap=16M$0x30000000 autorun=1' \ -fsdev local,id=f,path=/srv/vmshare,security_model=mapped-file \ -device virtio-9p-pci,fsdev=f,mount_tag=hostshare,addr=4 \ -serial stdio -monitor none ``` `memmap=` only reserves guest RAM for the reproducer's userspace virtio driver; `autorun=1` makes the guest's init start the reproducer. Neither matters to the bug. ## Emulated/Virtualized environment - Operating system: Linux, minimal Debian 13 userland (busybox + python3) booted as an initramfs - OS/kernel version: Linux 6.1.0-53-cloud-amd64 (Debian stock kernel) - Architecture: x86_64 ## Description of problem A guest with a writable virtio-9p share (`-fsdev local`) can escape the share. It can read and write host files outside the export that the QEMU process can access, and run commands on the host as the QEMU user. QEMU keeps running afterwards. The attacker is root inside the guest, using a userspace program that drives its own virtio-9p device with well-formed 9P requests. Nothing is needed from the host side. Host ASLR is defeated through the bug itself. Cause: `v9fs_co_open2()` (hw/9pfs/cofile.c:168) holds the path write lock while it replaces `fidp->path` on a worker thread: it frees the old buffer and copies in the new path. Meanwhile `v9fs_xattrwalk()` (hw/9pfs/9p.c:4073) and `v9fs_walk()` (hw/9pfs/9p.c:1980) copy the same `fidp->path` on the main thread without taking the read lock. If the main thread reads the old `size` before the free and copies the bytes after the worker has reused that chunk for the new, shorter path, the new fid ends up with a `V9fsPath` whose `size` is the old length but which contains no NUL inside that length. Every later `v9fs_path_copy()` of that fid copies exactly `size` bytes into a fresh chunk. The backend therefore sees `./A/B/C/` followed by stale heap bytes, which the guest grooms to `../../../../..`. `local_open_nofollow()` (hw/9pfs/9p-local.c:61) resolves the result one `openat()` per component and does not reject `..`. A Twalk from that fid therefore lands above the export, at the host's `/`. From there the guest can: - read `/etc/passwd` and any file the QEMU user can read. In our setup that included another tenant's mode-600 file owned by the same user. `/etc/shadow` was correctly denied. - create files in the host's `/tmp`. - read `/proc/<qemu-pid>/maps` (the ASLR leak) and the host's libc. - write `/proc/<qemu-pid>/mem`. The reproducer places a short stub over `fstatfs64()` and sends one Tstatfs, which makes QEMU call `system()`. It then restores the original bytes. Observed output of the command run on the host: ``` command run ON THE HOST by user qemu-vm (uid 2001), host name kvm-host-01, parent process: qemu-system-x86 pid 1 Linux kvm-host-01 6.1.0-51-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.177-1 (2026-07-16) x86_64 GNU/Linux ``` Results (real guest under KVM, one cold boot per run): | QEMU | QEMU user | escape + host command | QEMU segfaulted instead | |------|-----------|-----------------------|-------------------------| | Debian 10.0.13 package | unprivileged | 4/5 | 1/5 | | Debian 7.2.22 package | unprivileged | 2/5 | 3/5 | | master 28e7aad522 | root | 11/11 | 0/11 | | master 28e7aad522 + attached patch | root | 0 escapes in 9 runs of 100–150 s each (\~24 000 race rounds per run) | 0 | Every unpatched run ended in one of these two ways within about 5 s of starting the reproducer. The segfault is the other outcome of the same race. The unlocked Twalk copy was introduced by 8d6cb100731c ("9pfs: reduce latency of Twalk", v6.1.0). The worker-thread rewrite and the unlocked Txattrwalk copy date from 2011. This bug is distinct from CVE-2026-48004 (missing rename lock in `v9fs_co_readdir_many`): that fix is present in both the 10.0.13 package and master, and both are affected. ## Steps to reproduce 1. Create a writable share at most two levels below `/` (for example `/srv/vmshare`), owned by the user QEMU will run as. The `..` climb in this reproducer is 5 levels, and 3 of those are used by its own directories. 2. Build the guest initramfs: - Use a stock Debian 13 userland with `python3-minimal` and `busybox-static` (`guest/Dockerfile.guest`, then `docker export`). - Add `guest/escape9p.py` as `/root/escape9p.py` and `guest/init` as `/init`. - Pack it with `find . | cpio -o -H newc | gzip > initramfs.gz`. - Use any x86_64 distribution kernel as `vmlinuz`. We used Debian's `vmlinuz-6.1.0-53-cloud-amd64`. 3. Start QEMU with the command line above as an unprivileged user, for example `setpriv --reuid <uid> --regid <gid> --groups <kvm-gid> qemu-system-x86_64 ...`. `host_run2.sh` in the attachment does this. 4. The guest runs `python3 /root/escape9p.py` automatically. Without `autorun=1`, run it from the guest shell on the serial console. The script: - binds to the virtio-9p device through sysfs and attaches. - creates its working directories and grooms the heap. - races Tlcreate against bursts of Txattrwalk on one directory fid, and probes each new xattr fid with `Twalk(fid, ["etc"])`. - on a walk that should have failed, walks to `..` (the host's `/`), reads host files, creates `/tmp/WRITTEN_BY_GUEST.txt`, and performs the code-execution step described above. - prints `done: ESCAPED` or `done: NO escape`. 5. On the host, check that `/tmp/WRITTEN_BY_GUEST.txt` and `/tmp/HOST_COMMAND_OUTPUT.txt` exist and are owned by the QEMU user, and that the QEMU process is still running. If QEMU segfaulted instead, boot the guest again. Alternative without a guest kernel: `original_finding/repro.sh` drives the same race through `-accel qtest` against a QEMU build at `$QEMU`. ## Additional information - Tested with `security_model=mapped-file` only. `passthrough` and `none` were not tested. - Not tested under libvirt with sVirt/SELinux or AppArmor confinement. Such a profile would limit which host files are reachable, and may block the `/proc/<pid>/mem` write. - Attached patch (`original_finding/patches/01-approved-hw_9pfs_cofile.c.patch`): applies to master, and with it applied the reproducer never reached anything outside the share (see the table). - Attachments: `escape9p.py`, `init`, `Dockerfile.guest`, `host_run2.sh`, full guest console logs for every run, the original qtest reproducer, the patch, and a screen recording (`qemu_9pfs_vm_escape_stock_debian13.mp4`) showing the host side and the guest console. - Finding ID: ANT-2026-WILI89BA ("9pfs: Tlcreate frees fid path on worker thread, use-after-free in Twalk"). [ANT-2026-WILI89BA_qemu_9pfs_vm_escape.zip](/uploads/d18ad9ec53f4ea303eb1c464a88e538e/ANT-2026-WILI89BA_qemu_9pfs_vm_escape.zip)