Imported by the "Security Issuer Importer" bot, on behalf of the original reporter who disclosed via qemu-security list: * From: `Feifan Qian <bea1e@proton.me>` * Date: `25 May, 2026` * Message ID: `<Y9F02M3_xfQkgFY8kTqMywpa3whQmRyAhBEgsaYseROJYGDjSeCQ54oB1pztI106kZELwIcs4CbbKGgpIZicLHgYODtJiNdbs7fCyERqZcI=@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. **NOTE:** this disclosure includes a [report.md](/uploads/62af2dfe7a05b8defeeb2fd52ef9bf9d/report.md) file which provides a markdown formatted version of the disclosure which may include more information that this bug description. ---- I'm writing to report a security vulnerability in QEMU's vfio-user PCI device handling. A malicious vfio-user backend can return a crafted DEVICE_GET_REGION_INFO reply that causes QEMU's vfio-user client to allocate a wrapped-small message buffer and write past it during device realization. This issue was discovered through AI-assisted static code auditing and passed human validation before disclosure. The affected code is in the QEMU vfio-user client path, specifically the vfio-user-pci device realization flow that queries region information from the configured backend socket. I reproduced the issue on QEMU 11.0.50, commit f5a2438405d4ae8b62de7c9b39fac0b2155ee544, with CONFIG_VFIO_USER enabled. The vulnerable runtime configuration requires QEMU to be launched with a vfio-user-pci device connected to an attacker-controlled or compromised vfio-user backend. This should be treated as a security issue for vfio-user deployments because QEMU's security documentation treats external protocol inputs and passthrough-device-related inputs as untrusted, and the vfio-user protocol documentation explicitly says clients should not trust servers and should validate input to prevent denial of service and buffer overflows. Here, the backend controls the region-info argsz field, QEMU accepts it without a maximum bound or overflow check, and the value reaches a heap allocation and header initialization write. The confirmed impact is QEMU process denial of service from an AddressSanitizer-detected heap-buffer-overflow. In an unsanitized build, the same data flow can produce client heap memory corruption and can cause QEMU to send bytes beyond the undersized allocation back to the backend. I assessed this as CVSS v3.1 6.6 Medium (AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H), scoped to systems where an attacker can run or compromise the vfio-user backend selected by QEMU. A detailed technical report with full reproduction steps and a minimal proof of concept is attached as disclosure.zip. The PoC starts a malicious vfio-user Unix socket backend, launches qemu-system-x86_64 with vfio-user-pci, and ASan confirms a heap-buffer-overflow in vfio_user_request_msg after a crafted DEVICE_GET_REGION_INFO reply with argsz=0xfffffff8. I'm happy to provide further details, test proposed fixes, or coordinate on an appropriate disclosure timeline. [report.md](/uploads/62af2dfe7a05b8defeeb2fd52ef9bf9d/report.md) [disclosure.zip](/uploads/f84994440f0b3fc8c17cfc82821404cc/disclosure.zip)