<!-- This is the upstream QEMU issue tracker. If you are able to, it will greatly facilitate bug triage if you attempt to reproduce the problem with the latest qemu.git master built from source. See https://www.qemu.org/download/#source for instructions on how to do this. QEMU generally supports the last two releases advertised on https://www.qemu.org/. Problems with distro-packaged versions of QEMU older than this should be reported to the distribution instead. See https://www.qemu.org/contribute/report-a-bug/ for additional guidance. If this is a security issue, ensure this ticket is marked 'confidential' before submission. See https://www.qemu.org/contribute/security-process/ for additional guidance --> **Automated-tool disclosure:** AI-assisted source analysis helped identify this issue. I manually reviewed the affected source, validated the trigger and resulting mapping, and practically demonstrated that it can supply a capability in a guest-to-host escape chain. The attached reproducer is human-reviewed source code and does not exercise the full escape chain. **Classification note:** I am not sure whether this standalone issue qualifies as a security issue under QEMU's published guidelines. It crosses the guest-kernel-to-SMM isolation boundary, and Q35 with a virtualization accelerator is a supported configuration, but the guidelines also treat some virtual-device misbehavior requiring guest kernel or root privileges as a hardening bug. I have therefore prepared this as a confidential report so the QEMU security team can make that determination. The confidential marking is not intended to assert that the standalone bug qualifies for security handling. ## Host environment - Operating system: Debian GNU/Linux 12 (bookworm) - OS/kernel version: Linux 6.1.0-51-amd64, Debian 6.1.177-1 (2026-07-16) - Architecture: x86_64 - QEMU flavor: qemu-system-x86_64 - QEMU version: 11.0.92 (v11.1.0-rc2-9-gb428fe0362), commit b428fe036233cbd15d37e3c027ab6ca4d3661a80 - QEMU command line: ```sh /home/artem/qemuctf/patched-stack/qemu/bin/qemu-system-x86_64 \ -name debian-12-qemu \ -machine q35,accel=kvm:tcg \ -cpu max \ -smp 4 \ -m 8G \ -drive file=/home/artem/vm/debian-12-qemu/disk.qcow2,if=virtio,format=qcow2 \ -drive file=/home/artem/vm/debian-12-qemu/seed.iso,if=virtio,format=raw,readonly=on \ -nic user,model=virtio-net-pci,mac=52:54:00:12:34:56,hostfwd=tcp:127.0.0.1:2222-:22 \ -object rng-random,filename=/dev/urandom,id=rng0 \ -device virtio-rng-pci,rng=rng0 \ -display none \ -serial file:/home/artem/vm/debian-12-qemu/console.log \ -monitor unix:/home/artem/vm/debian-12-qemu/monitor.sock,server=on,wait=off ``` ## Emulated/Virtualized environment - Operating system: Debian GNU/Linux 12 (bookworm) - OS/kernel version: Linux 6.1.0-51-cloud-amd64, Debian 6.1.177-1 (2026-07-16) - Architecture: x86_64 ## Description of problem <!-- Describe the problem, including any error/crash messages seen. --> The 16-bit VAPIC setup hypercall lets a privileged guest choose both the base and size of a priority-1000 writable RAM alias. QEMU does not verify that the resulting interval belongs to the VAPIC option ROM. On Q35, a guest can therefore place the alias over `0xa0000..0xbffff`, bypassing the chipset's locked-SMRAM view and modifying memory that will execute in System Management Mode. Current qemu.git master, commit `fa19879df1658f96ac07365fca8835b7decd6995`, remains affected by source inspection and runtime validation. The relevant code is: - [`vapic_write()` at `hw/i386/vapic.c:644-681`](https://gitlab.com/qemu-project/qemu/-/blob/fa19879df1658f96ac07365fca8835b7decd6995/hw/i386/vapic.c#L644-681) - [`vapic_map_rom_writable()` at `hw/i386/vapic.c:587-623`](https://gitlab.com/qemu-project/qemu/-/blob/fa19879df1658f96ac07365fca8835b7decd6995/hw/i386/vapic.c#L587-623) For a 16-bit write to I/O port `0x7e`, `vapic_write()` derives `rom_paddr` from guest-controlled `CS:EIP` and adds the guest-supplied port value. `vapic_map_rom_writable()` then: 1. aligns this guest-selected value to a 512-byte ROM block; 2. calls `memory_region_find(mr, 0, 1)`, selecting the full guest-RAM backing rather than validating the region at the requested address; 3. reads the alias length from the guest-controlled byte `ram[rom_paddr + 2]`; and 4. creates a `kvmvapic-rom` alias at overlap priority 1000 without checking that its rounded base and end remain inside the option-ROM window. In the attached reproducer, the setup write executes at GPA `0x9fe10`, selecting block `0x9fe00`, and guest RAM byte `0x9fe02` is `0xff`. The raw length is therefore `0xff * 512 = 0x1fe00` bytes. QEMU's page rounding changes this into `[0x9f000, 0xc0000)`. The priority-1000 alias overrides the normal Q35 mappings for locked SMRAM at `[0xa0000, 0xc0000)`. The resume condition is practical and does not inherently require the attacker to control QEMU's management interface. Privileged guest code can install the suspend hook in advance. When the guest next enters S3, the hook arms the malicious firmware waking vector, which remains in place while the VM is suspended. The attacker can then wait for an ordinary resume initiated by a user, operator, or configured virtual wake source; the wake stub executes before the guest OS completes its normal resume. The `system_wakeup` HMP command in the reproducer is only a deterministic way to produce that ordinary wake event. ### Security relevance and scope uncertainty I am not asserting that this bug independently crosses a security boundary that QEMU promises to protect. I have prepared it for confidential triage because I am unsure whether it qualifies as a security issue under QEMU's guidelines. The QEMU [security process](https://www.qemu.org/contribute/security-process/) says that not every part of QEMU provides a security boundary and invites reports when the reporter thinks there may be a vulnerability or is unsure how a vulnerability affects QEMU. In particular, I do not know whether guest-kernel-to-SMM isolation on an accelerated Q35 machine is within the supported security boundary. Regardless of that security classification, this is incorrect device behavior: a hypercall whose documented purpose is to make the VAPIC option ROM writable can instead replace unrelated Q35 memory mappings. QEMU neither rejects the malformed setup nor constrains its resulting range to the option-ROM window. The immediate primitive crosses the guest kernel/SMM isolation boundary: a guest administrator can inject arbitrary code into locked SMRAM and have it execute in SMM. The Q35 `D_LCK` protection no longer prevents non-SMM guest software from modifying the SMM backing memory. The project's [published security model](https://www.qemu.org/docs/master/system/security.html) explicitly treats the guest as untrusted and lists Q35 with a virtualization accelerator as a supported guest-isolation configuration. On the other hand, its "degraded guest behaviour" guidance says that virtual-device misbehavior requiring guest kernel or root privileges will generally be treated as a hardening bug, and it does not explicitly identify guest-kernel-to-SMM isolation as a supported security boundary. I therefore defer classification to the QEMU security team. I nevertheless used this primitive with other, separately reported vulnerabilities to obtain a complete guest-to-host escape and practically demonstrated that chain from a Debian 12 guest. Those other issues are independent and intentionally omitted here. I defer the standalone severity and CVE decision to the QEMU security team. ### Suggested fix QEMU should bind the writable alias to the VAPIC option ROM that QEMU actually loaded, rather than trusting an address and length reconstructed from guest state. At minimum, before creating the alias, it should reject any raw or page-rounded interval whose base or end lies outside the PC option-ROM window (`0xc0000..0xdffff`), perform overflow-safe end checks, and verify the expected VAPIC ROM identity. The strongest fix would retain the exact address and size assigned when `kvmvapic.bin` is loaded and require the setup hypercall to match that range. The validation must occur before deleting an existing alias or calling `memory_region_init_alias()`. A regression test should attempt setup writes from below `0xc0000` and with a size byte that would cross `0xe0000`, then confirm that no alias is created. ## Steps to reproduce 1. Start an x86 Q35/KVM guest with ACPI S3 and an HMP monitor. The complete command line used for practical validation is included above. 2. Copy the attached `qemu-vapic-smram-reproducer.tar.gz` into the guest, extract it, and install the build prerequisites. On Debian: ```sh tar -xzf qemu-vapic-smram-reproducer.tar.gz cd qemu-vapic-smram-reproducer sudo apt-get install build-essential linux-headers-$(uname -r) make sudo insmod vapic_s3_repro.ko ``` 3. In the guest, run `sudo systemctl suspend`. In the HMP monitor, run `system_wakeup` to resume it. 4. In HMP, run `info mtree` and inspect the system-memory region tree. A vulnerable build shows priority-1000 `kvmvapic-rom` covering `0x000000000009f000..0x00000000000bffff`, overlapping `smram-region` at `0x00000000000a0000..0x00000000000bffff`. 5. In the guest, confirm the messages with `sudo dmesg | tail -n 20`, then unload the module with `sudo rmmod vapic_s3_repro`. Reset or stop the test VM to remove the QEMU-side alias. The observable mapping is sufficient to demonstrate the bug. The reproducer deliberately does not write an SMM payload or invoke any other vulnerability. <!-- Note: if this issue was discovered with the assistance of automated tooling LLM, static analysis, fuzzers), the reporter must disclose that in the description. The steps to reproduce, and any other findings, must be fully validated by the user of the tool prior to submission. --> ## Additional information <!-- Attach logs, stack traces, screenshots, etc. Compress the files if necessary. If using libvirt, libvirt logs and XML domain information may be relevant. If attaching binary test cases you should describe where they were obtained from, preferably linking to the original source. We greatly prefer test cases in the form of source code that can be audited before compiling by the engineer. --> - Runtime validation was performed on upstream-derived commit `b428fe036233cbd15d37e3c027ab6ca4d3661a80` and repeated on current master `fa19879df1658f96ac07365fca8835b7decd6995` (QEMU 11.1.50). - The exact attached archive builds against the listed Debian kernel's installed headers without compiler warnings. The resulting module loaded under that matching kernel for runtime testing. - The attached archive contains only the kernel-module C source, a Makefile, and detailed run instructions. - I found no public QEMU issue or CVE matching this VAPIC alias-range flaw. A confidential report may of course already exist. - Reporter: "Artem Dinaburg" <artem@trailofbits.com> <!-- The line below ensures that proper tags are added to the issue. Please do not remove it. --> [qemu-vapic-smram-reproducer.tar.gz](/uploads/2a8d02b598422323a209d3adf936ff4e/qemu-vapic-smram-reproducer.tar.gz)