Imported by the "Security Issuer Importer" bot, on behalf of the original reporter who disclosed via qemu-security list: * From: `Cyber_black <Cyberblackk@proton.me>` * Date: `25 May, 2026` * Message ID: `<wdyz8V2haIzRDnChRcer3QqXOS17Ru-br3H04ViT6hgvm9lVdd7bpb_8I3aN1xfYvT3woCpzHD86HTjHDfK_4MZ6To34AK5XAzFZgXRW_pI=@proton.me>` **NOTE:** the original reporter can not be copied on this issue so cannot view this ticket while it remains marked confidential. If further information is needed about the disclosure, contact the reporter directly. ---- ## Host environment Operating system: Debian OS/kernel version: Linux Enes 6.12.88+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.88-1 (2026-05-15) x86_64 GNU/Linux Architecture: x86_64 QEMU flavor: qemu-system-x86_64 QEMU version: QEMU emulator version 10.0.8 (Debian 1:10.0.8+ds-0+deb13u1+b2) Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers QEMU command line: ``` ./build/qemu-system-x86_64 -M q35,accel=kvm -m 4096 -cpu host -device virtio-gpu-pci,blob=true -display gtk -drive file=debian.qcow2,if=virtio,format=qcow2 ``` Emulated/Virtualized environment Operating system: Debian OS/kernel version: Linux Enes 6.12.88+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.88-1 (2026-05-15) x86_64 GNU/Linux Architecture: x86_64 ## Description of problem In virtio_gpu_scanout_blob_to_fb(), fb->offset is computed using 32-bit arithmetic: ``` fb->offset = ss->offsets[0] + ss->r.x * fb->bytes_pp + ss->r.y * fb->stride; ``` fb->offset is uint32_t and the operands are guest-controlled, making integer wraparound possible before the later bounds validation: ``` fbend = fb->offset; fbend += (uint64_t) fb->stride * ss->r.height; if (fbend > blob_size) return false; ``` The wrapped fb->offset is later used in virtio_gpu_do_set_scanout(): ``` void *ptr = data + fb->offset; ``` I confirmed the integer overflow / truncation behavior and wrote a minimal guest-side PoC that reaches the SET_SCANOUT_BLOB path with crafted values causing 32-bit wraparound. Example values: ``` stride = 4096 r.y = 1048577 ``` Arithmetic result: ``` 1048577 * 4096 = 0x100001000 ``` After uint32_t truncation: ``` fb->offset = 0x1000 ``` This demonstrates controllable arithmetic truncation before validation. I have not yet demonstrated a reliable host OOB read/write primitive or crash from this issue alone. In most cases the wrapped value appears to become a smaller in-range offset, which seems to reduce exploitability. This appears to be a real arithmetic bug with unclear security impact. Steps to reproduce - Build recent qemu.git master with virtio-gpu blob support enabled. - Start QEMU using: ``` ./build/qemu-system-x86_64 -M q35,accel=kvm -m 4096 -cpu host -device virtio-gpu-pci,blob=true -display gtk -drive file=debian.qcow2,if=virtio,format=qcow2 ``` - Inside the guest, run the attached PoC. - The PoC submits a crafted VIRTIO_GPU_CMD_SET_SCANOUT_BLOB request where: ``` r.y * stride ``` exceeds 32 bits and wraps before validation. - Observe wrapped framebuffer offset behavior in the host virtio-gpu path. ## Additional information Suggested mitigation: Perform the framebuffer offset computation in uint64_t and validate it before truncating/storing into fb->offset. Example: ``` uint64_t off = (uint64_t)ss->offsets[0] + (uint64_t)ss->r.x * fb->bytes_pp + (uint64_t)ss->r.y * fb->stride; if (off > UINT32_MAX) return false; fb->offset = off; ``` [virtio_gpu_overflow_poc.c](/uploads/d6ad947e10c7ff0ef45db6b0302db891/virtio_gpu_overflow_poc.c)