Reporter: Ankur Saini \<ankur98saini@gmail.com\> Date: 29-07-2026 ## Summary `virtio_gpu_resource_create_blob()` does not verify that mapped backing covers the declared blob size. A 16 KiB scanout backed by one byte causes a host heap out-of-bounds read, and VNC returns adjacent host heap bytes as framebuffer pixels to the requesting client. ## Impact When a VNC client requests the affected framebuffer, QEMU returns adjacent host heap bytes as framebuffer pixels to that client. ## Prerequisites - The optional blob scanout path is enabled with `blob=on`. For the tested plain non-virgl/non-rutabaga device, QEMU also requires `/dev/udmabuf` and an fd-backed memory backend with file seals. - To return the bytes to the same guest, the VNC listener is reachable from that guest. This is not normal VNC placement. ## Role of VNC VNC is the disclosure sink, not the root cause. When VNC is configured and a client requests a framebuffer update, QEMU's host-side VNC server copies the invalid scanout, performs the OOB read, and sends the copied bytes to that client. The leak therefore goes to the VNC client, wherever it runs; it does not automatically go to the guest. A VNC client normally runs outside the guest. The PoC deliberately runs a minimal client inside the guest and connects it to the host listener only to demonstrate disclosure back to the malicious guest. With no connected client requesting an update, VNC does not return the bytes. ## Tooling disclosure This issue was initially identified with LLM-assisted static analysis, then validated through direct source review, the attached guest userspace PoC, AddressSanitizer, an ordinary-build disclosure capture, and host-side GDB. ## Host environment **Operating system:** Ubuntu 26.04 LTS **OS/kernel version:** `Linux user-VMware-Virtual-Platform 7.0.0-28-generic #28-Ubuntu SMP PREEMPT_DYNAMIC Sun Jun 21 01:01:36 UTC 2026 x86_64 GNU/Linux` **Architecture:** x86_64 **QEMU flavor:** qemu-system-x86_64 **QEMU version:** `QEMU emulator version 11.0.91` **qemu.git revision:** `299e7557ed15a9a325620698add379a3ce2d1d95` (2026-07-27, `Merge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu into staging`) **QEMU command line:** ```bash /home/user/Desktop/qemu/build/qemu-system-x86_64 \ -L /home/user/Desktop/qemu/pc-bios \ -name ubuntu-simple-vgpu-002 \ -object memory-backend-memfd,id=vmram,size=2560M \ -machine q35,accel=kvm,memory-backend=vmram \ -cpu host \ -smp 4 \ -device virtio-vga,blob=on,ioeventfd=off,max_outputs=1 \ -display none \ -vnc 127.0.0.1:1 \ -drive file=/home/user/Desktop/vm/ubuntu-2604.qcow2,if=virtio,format=qcow2,snapshot=on,cache=writeback \ -netdev user,id=net0,hostfwd=tcp:127.0.0.1:2222-:22 \ -device virtio-net-pci,netdev=net0 ``` The VirtIO NIC provides SSH access and deliberately lets this guest reach the host-side VNC listener as `10.0.2.2:5901`. It is not involved in creating the invalid VirtIO-GPU resource. In a conventional deployment, the VNC client is outside the guest, so the leaked bytes are delivered to that external client. The guest enumerates the GPU as: ``` 00:01.0 VGA compatible controller [0300]: Red Hat, Inc. Virtio 1.0 GPU [1af4:1050] (rev 01) ``` ## Emulated/Virtualized environment **Operating system:** Ubuntu 26.04 LTS **OS/kernel version:** `Linux user-Standard-PC-Q35-ICH9-2009 7.0.0-28-generic #28-Ubuntu SMP PREEMPT_DYNAMIC Sun Jun 21 01:01:36 UTC 2026 x86_64 GNU/Linux` **Architecture:** x86_64 ## Steps to reproduce 1. Build qemu.git master normally: ```bash git clone https://github.com/qemu/qemu.git cd qemu mkdir build cd build ../configure make -j4 ``` For AddressSanitizer, use a separate build directory: ```bash cd .. mkdir build-asan cd build-asan ../configure --enable-asan make -j4 ``` 2. Confirm that the host provides `/dev/udmabuf`: ```bash ls -l /dev/udmabuf ``` If it is absent, try: ```bash sudo modprobe udmabuf ls -l /dev/udmabuf ``` Do not continue unless `/dev/udmabuf` exists and the QEMU process can open it. 3. Start an Ubuntu guest with the command line shown under **Host environment**. To obtain the sanitizer diagnostic, replace the ordinary binary with `build-asan/qemu-system-x86_64` and launch it with: ```bash export ASAN_OPTIONS=abort_on_error=1:halt_on_error=1:detect_leaks=0:symbolize=1 ``` The tested VNC endpoint uses RFB `None` authentication. The PoC defaults to `10.0.2.2:5901`, where `10.0.2.2` is the host address provided by QEMU user networking in the command above. With bridge, tap, libvirt, or another network topology, set `VNC_HOST` and `VNC_PORT` to an IPv4 VNC endpoint reachable from the guest. 4. Copy the attached source file into the guest and connect over SSH: ```bash scp -P 2222 virtio_gpu_002_repro.c user@127.0.0.1:~/ ssh -p 2222 user@127.0.0.1 ``` 5. Compile the PoC inside the guest: ```bash gcc -O0 -g3 -Wall -Wextra -Wpedantic -Werror \ -o virtio_gpu_002_repro virtio_gpu_002_repro.c ``` 6. Run it as root: ```bash sudo ./virtio_gpu_002_repro ``` The PoC auto-detects a single VirtIO-GPU PCI display function. An explicit PCI BDF and VNC endpoint can be supplied when necessary: ```bash sudo VNC_HOST=10.0.2.2 VNC_PORT=5901 \ ./virtio_gpu_002_repro 0000:00:01.0 ``` The PoC temporarily stops the display manager, unbinds the guest `virtio-pci` driver, submits complete VirtIO-GPU commands through a split control queue, and restores the driver and display manager through its cleanup handler when QEMU remains alive. With the ASan build, QEMU aborts in `vnc_refresh_server_surface()`. With the ordinary build, the PoC receives the complete 16 KiB framebuffer through VNC and exits successfully. ## Suggested fix The suggested fix below was generated with AI assistance, so needs further verification as I am unfamiliar with this codebase. It validates the aggregate mapped length before initializing a non-empty blob backing. Applies the same invariant to inline creation, deferred attachment, and blob migration load. Exact and oversized backing remain valid, and zero-entry creation remains valid for later `RESOURCE_ATTACH_BACKING`. The checks belong after the inline map in `virtio_gpu_resource_create_blob()` (`hw/display/virtio-gpu.c:366-375`), after the deferred map but before `virtio_gpu_init_udmabuf()` (`hw/display/virtio-gpu.c:989-998`), and before restoring blob mappings during migration (`hw/display/virtio-gpu.c:1490-1501`). On a rejected attach, release only the newly created iovec and address array so the resource remains reusable without invoking blob finalization. ```diff diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c --- a/hw/display/virtio-gpu.c +++ b/hw/display/virtio-gpu.c @@ -372,6 +372,14 @@ return; } + if (res->iov_cnt && + iov_size(res->iov, res->iov_cnt) < res->blob_size) { + cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER; + virtio_gpu_cleanup_mapping(g, res); + g_free(res); + return; + } + virtio_gpu_init_udmabuf(res); QTAILQ_INSERT_HEAD(&g->reslist, res, next); } @@ -990,6 +998,17 @@ &res->addrs, &res->iov, &res->iov_cnt); if (ret < 0) { cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC; + return; + } + + if (!res->image && res->iov_cnt && + iov_size(res->iov, res->iov_cnt) < res->blob_size) { + cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER; + virtio_gpu_cleanup_mapping_iov(g, res->iov, res->iov_cnt); + res->iov = NULL; + res->iov_cnt = 0; + g_free(res->addrs); + res->addrs = NULL; return; } @@ -1491,6 +1510,14 @@ for (i = 0; i < res->iov_cnt; i++) { res->addrs[i] = qemu_get_be64(f); res->iov[i].iov_len = qemu_get_be32(f); + } + + if (res->iov_cnt && + iov_size(res->iov, res->iov_cnt) < res->blob_size) { + g_free(res->addrs); + g_free(res->iov); + g_free(res); + return -EINVAL; } if (!virtio_gpu_load_restore_mapping(g, res)) { ``` ## Evidence ### AddressSanitizer build ``` ==213189==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! ==213189==WARNING: ASan is ignoring requested __asan_handle_no_return: stack type: default top: 0x7ffe96303000; bottom 0x71ae15ce4000; size: 0x0e508061f000 (15738914074624) False positive error reports may follow For details see https://github.com/google/sanitizers/issues/189 ================================================================= ==213189==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x71ee18e5c771 at pc 0x75ae1ccecc6f bp 0x7ffe96300250 sp 0x7ffe962ff9f8 READ of size 64 at 0x71ee18e5c771 thread T0 #0 0x75ae1ccecc6e in MemcmpInterceptorCommon(void*, int (*)(void const*, void const*, unsigned long), void const*, void const*, unsigned long) ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:849 #1 0x75ae1cced834 in memcmp ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:880 #2 0x75ae1cced834 in memcmp ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:875 #3 0x6389799b9fc2 in vnc_refresh_server_surface ../../../qemu/ui/vnc.c:3221 #4 0x6389799ba363 in vnc_refresh ../../../qemu/ui/vnc.c:3266 #5 0x63897a8d257d in dpy_refresh ../../../qemu/ui/console.c:832 #6 0x63897a8cdbb7 in gui_update ../../../qemu/ui/console.c:107 #7 0x63897adf67c5 in timerlist_run_timers ../../../qemu/util/qemu-timer.c:593 #8 0x63897adf68f6 in qemu_clock_run_timers ../../../qemu/util/qemu-timer.c:607 #9 0x63897adf6ec8 in qemu_clock_run_all_timers ../../../qemu/util/qemu-timer.c:694 #10 0x63897ade80c7 in main_loop_wait ../../../qemu/util/main-loop.c:605 #11 0x63897a4cd0b1 in qemu_main_loop ../../../qemu/system/runstate.c:950 #12 0x63897abfe06a in qemu_default_main ../../../qemu/system/main.c:50 #13 0x63897abfe1be in main ../../../qemu/system/main.c:93 #14 0x75ae1b22a600 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:59 #15 0x75ae1b22a717 in __libc_start_main_impl ../csu/libc-start.c:360 #16 0x63897993da24 in _start (/home/user/Desktop/qemu-audit/network/build-asan/qemu-system-x86_64+0xb33a24) (BuildId: e7153b37b4fd2088ae033017c2d19b24b41afce9) 0x71ee18e5c771 is located 0 bytes after 33-byte region [0x71ee18e5c750,0x71ee18e5c771) allocated by thread T0 here: #0 0x75ae1cd2b40f in calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:74 #1 0x75ae1c7ae121 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x68121) (BuildId: 2426ee6f828a10bf4da963a4c474752c33742359) #2 0x63897a4b40e4 in address_space_map ../../../qemu/system/physmem.c:3746 #3 0x63897a51ab51 in dma_memory_map /home/user/Desktop/qemu/include/system/dma.h:212 #4 0x63897a5244ab in virtio_gpu_create_mapping_iov ../../../qemu/hw/display/virtio-gpu.c:897 #5 0x63897a51e38e in virtio_gpu_resource_create_blob ../../../qemu/hw/display/virtio-gpu.c:366 #6 0x63897a52588a in virtio_gpu_simple_process_cmd ../../../qemu/hw/display/virtio-gpu.c:1041 #7 0x63897a525d3c in virtio_gpu_process_cmdq ../../../qemu/hw/display/virtio-gpu.c:1109 #8 0x63897a526938 in virtio_gpu_handle_ctrl ../../../qemu/hw/display/virtio-gpu.c:1180 #9 0x63897a5269eb in virtio_gpu_ctrl_bh ../../../qemu/hw/display/virtio-gpu.c:1188 #10 0x63897ade2bc5 in aio_bh_call ../../../qemu/util/async.c:173 #11 0x63897ade2ff2 in aio_bh_poll ../../../qemu/util/async.c:220 #12 0x63897ad9fd1c in aio_dispatch ../../../qemu/util/aio-posix.c:390 #13 0x63897ade3f09 in aio_ctx_dispatch ../../../qemu/util/async.c:365 #14 0x75ae1c7a6b9a (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x60b9a) (BuildId: 2426ee6f828a10bf4da963a4c474752c33742359) #15 0x75ae1c7a6e0f in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x60e0f) (BuildId: 2426ee6f828a10bf4da963a4c474752c33742359) #16 0x63897ade7b71 in glib_pollfds_poll ../../../qemu/util/main-loop.c:292 #17 0x63897ade7cee in os_host_main_loop_wait ../../../qemu/util/main-loop.c:315 #18 0x63897ade8015 in main_loop_wait ../../../qemu/util/main-loop.c:594 #19 0x63897a4cd0b1 in qemu_main_loop ../../../qemu/system/runstate.c:950 #20 0x63897abfe06a in qemu_default_main ../../../qemu/system/main.c:50 #21 0x63897abfe1be in main ../../../qemu/system/main.c:93 #22 0x75ae1b22a600 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:59 #23 0x75ae1b22a717 in __libc_start_main_impl ../csu/libc-start.c:360 #24 0x63897993da24 in _start (/home/user/Desktop/qemu-audit/network/build-asan/qemu-system-x86_64+0xb33a24) (BuildId: e7153b37b4fd2088ae033017c2d19b24b41afce9) SUMMARY: AddressSanitizer: heap-buffer-overflow ../../../qemu/ui/vnc.c:3221 in vnc_refresh_server_surface Shadow bytes around the buggy address: 0x71ee18e5c480: fa fa 00 00 00 00 01 fa fa fa fa fa fa fa fa fa 0x71ee18e5c500: fa fa 00 00 00 00 01 fa fa fa fa fa fa fa fa fa 0x71ee18e5c580: fa fa 00 00 00 00 01 fa fa fa 00 00 00 00 01 fa 0x71ee18e5c600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x71ee18e5c680: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x71ee18e5c700: fa fa fa fa fa fa fa fa fa fa 00 00 00 00[01]fa 0x71ee18e5c780: fa fa 00 00 00 00 01 fa fa fa fa fa fa fa fa fa 0x71ee18e5c800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x71ee18e5c880: fa fa fa fa fa fa fa fa fa fa 00 00 00 00 01 fa 0x71ee18e5c900: fa fa 00 00 00 00 01 fa fa fa 00 00 00 00 01 fa 0x71ee18e5c980: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==213189==ABORTING ``` ### Ordinary build: confirmed guest-visible disclosure The same PoC was then run against a freshly rebuilt, unmodified ordinary binary from the same clean revision using the exact command under **Host environment**. QMP reported `share=true` and `seal=true` for `/objects/vmram`, confirming the omitted properties use their documented defaults. ``` using GPU 0000:00:01.0, page size 4096 stopped display-manager detached GPU 0000:00:01.0 from virtio-pci using device MMIO byte at guest physical 0xfe801014 as the one-byte backing device features: page0=3000000a page1=00000101 control queue max=64 created 192 one-byte MMIO-backed blobs; target=96 VNC framebuffer is 64x64 saved leaked framebuffer to /tmp/virtio_gpu_002_vnc_leak.2835.bin host-pointer candidate at pixel byte 0x10: 0x000060390128eb50 host-pointer candidate at pixel byte 0x128: 0x000072bcbd812ac8 host-pointer candidate at pixel byte 0x1c0: 0x000060390128eec0 host-pointer candidate at pixel byte 0x1c8: 0x000060390128edb0 host-pointer candidate at pixel byte 0x1f8: 0x000060390128eda0 host-pointer candidate at pixel byte 0x210: 0x000060390128eab0 host-pointer candidate at pixel byte 0x218: 0x000060390128efb0 host-pointer candidate at pixel byte 0x238: 0x000060390106dcb0 host-pointer candidate at pixel byte 0x260: 0x000060390128eda0 host-pointer candidate at pixel byte 0x378: 0x000072bcbd812ac8 host-pointer candidate at pixel byte 0x410: 0x000060390128f110 host-pointer candidate at pixel byte 0x418: 0x000060390128f000 host-pointer candidate at pixel byte 0x448: 0x000060390128eff0 host-pointer candidate at pixel byte 0x460: 0x000060390128ed00 host-pointer candidate at pixel byte 0x468: 0x000060390128f200 host-pointer candidate at pixel byte 0x488: 0x000060390106dcb0 guest received 16384 framebuffer bytes; pointer candidates=565 POINTER DISCLOSURE: the guest received host-pointer candidates through QEMU VNC rebound GPU 0000:00:01.0 to virtio-pci restarted display-manager ``` Attachments: - `virtio_gpu_002_repro.c` — standalone guest userspace reproducer [virtio_gpu_002_repro.c](/uploads/52d98772bc8716b7e3c6b373d748ed2e/virtio_gpu_002_repro.c)