Imported by the "Security Issuer Importer" bot, on behalf of the original reporter who disclosed via qemu-security list: * From: `최예원 <woni9911@gmail.com>` * Date: `06 May, 2026` * Message ID: `<CAFgxCDz28sXebG6sWbM+5Mq7zN+X1z3fDsaonBW0D+hbeQfc3Q@mail.gmail.com>` **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. ---- I am reporting a guest-triggerable undefined-behavior bug in the virtio-sound PCM_INFO request handler. When a guest sends a VIRTIO_SND_R_PCM_INFO request with `count == 0`, the handler allocates the response buffer via `g_new0(virtio_snd_pcm_info, 0)`, which returns NULL, then forwards that NULL pointer as the source argument of `iov_from_buf()`. Inside `iov_from_buf_full()`, `memcpy(dst, NULL, 0)` is invoked. The C standard's `nonnull` attribute on memcpy's source parameter forbids NULL even when the length is 0, so this is undefined behavior; in current QEMU on glibc/x86_64 the call happens to be a no-op, but compiler optimizations are free to assume non-NULL and elide subsequent NULL checks, which can turn this into a NULL-deref crash (and potentially worse) on other toolchains or hardening flags. # Severity (proposed): MEDIUM - Guest-triggerable with no host interaction beyond ordinary -device virtio-sound-pci instantiation (no unusual flags). - At minimum a reliable DoS (segfault) under stricter hardening (e.g. -fno-delete-null-pointer-checks disabled, sanitizer builds). - Could provide an information-disclosure or write primitive if a later optimization eliminates a NULL check downstream of the affected memcpy. # Affected component hw/audio/virtio-snd.c :: virtio_snd_handle_pcm_info() (the iov_from_buf() call after the per-stream loop) reaches util/iov.c :: iov_from_buf_full() at the memcpy on line 33 Affected version I confirmed that bug manifests with the latest commit of master branch (commit a85c588d07). # Description `virtio_snd_handle_pcm_info()` services VIRTIO_SND_R_PCM_INFO requests. It reads `start_id`, `count`, and `size` from the guest-supplied `virtio_snd_query_info` body, validates the (`start_id`, `count`, `size`) combination, then builds the response: pcm_info = g_new0(virtio_snd_pcm_info, count); for (uint32_t i = 0; i < count; i++) { ... /* fill pcm_info[i] */ } cmd->payload_size = sizeof(virtio_snd_pcm_info) * count; cmd->resp.code = cpu_to_le32(VIRTIO_SND_S_OK); iov_from_buf(cmd->elem->in_sg, cmd->elem->in_num, sizeof(virtio_snd_hdr), pcm_info, /* <- can be NULL */ cmd->payload_size); /* <- 0 when count==0 */ The validation block above this code only rejects requests where `start_id + count > s->snd_conf.streams`; it does NOT reject `count == 0`. A guest that sends a PCM_INFO request with `count = 0` takes the following path: 1. `pcm_info = g_new0(virtio_snd_pcm_info, 0)` returns NULL (glib's `g_malloc0(0)` returns NULL by contract). 2. The per-stream `for` loop body does not execute. 3. `cmd->payload_size = 0`. 4. `iov_from_buf(in_sg, in_num, 24, NULL, 0)` is called. Inside `iov_from_buf_full()` (util/iov.c:25), the loop is entered because `offset == sizeof(virtio_snd_hdr) == 24` is non-zero. When the first iov in `in_sg` is large enough to contain the header offset, the function reaches line 33: memcpy(iov[i].iov_base + offset, buf + done, len); /* buf == NULL, done == 0, len == 0 */ `memcpy`'s second parameter is declared `__attribute__((nonnull))` in glibc's `string.h`, so passing NULL there is undefined behavior even when `len == 0` (C11 7.24.1p2, restated in C23 7.26.1p2). UBSan catches this: ../util/iov.c:33:50: runtime error: null pointer passed as argument 2, which is declared to never be null /usr/include/string.h:44:28: note: nonnull attribute specified here In practice, on glibc/x86_64 with no optimization assumptions about nonnull, the memcpy currently completes as a no-op. With sufficiently aggressive inter-procedural analysis (or stricter C libraries / GCC versions enforcing nonnull), the compiler may elide subsequent NULL checks on `pcm_info`, or the runtime may abort the process. # Reproducer Build QEMU with UndefinedBehaviorSanitizer (--enable-sanitizers, or -fsanitize=undefined) and run the following shell script. The qtest commands are equivalent to what a guest driver could do via PCI config and MMIO writes — no host-side action is required after VM start. ``` cat <<'EOF' | qemu-system-i386 \ -display none -M pc,accel=qtest -smp 1 -cpu qemu32 -m 512M -nodefaults \ -device virtio-sound-pci,id=fdev_virtio_sound,audiodev=audio0 \ -audiodev none,id=audio0 \ -qtest stdio outl 0xcf8 0x80001000 inw 0xcfc outl 0xcf8 0x80001014 outl 0xcfc 0xffffffff outl 0xcf8 0x80001014 inl 0xcfc outl 0xcf8 0x80001014 outl 0xcfc 0xe0000000 outl 0xcf8 0x80001020 outl 0xcfc 0xffffffff outl 0xcf8 0x80001020 inl 0xcfc outl 0xcf8 0x80001020 outl 0xcfc 0xe0004000 outl 0xcf8 0x80001004 inw 0xcfc outl 0xcf8 0x80001004 outw 0xcfc 0x0007 write 0x100000 0x10 0x00002000000000001000000001000100 write 0x100010 0x10 0x00003000000000001000000002000000 write 0x101000 0x6 0x000001000000 write 0x102000 0x4 0x00000000 write 0x200000 0x4 0x00010000 write 0xe0004014 0x1 0x0f write 0xe0004012 0x2 0x0000 write 0xe0004018 0x2 0x0200 write 0xe0004020 0x8 0x0000100000000000 write 0xe0004028 0x8 0x0010100000000000 write 0xe0004030 0x8 0x0020100000000000 write 0xe000401c 0x2 0x0100 write 0xe0004030 0x8 0x004000e000000000 writew 0xe0007000 0x0000 EOF ``` # UBSan output ``` ../util/iov.c:33:50: runtime error: null pointer passed as argument 2, which is declared to never be null /usr/include/string.h:44:28: note: nonnull attribute specified here SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../util/iov.c:33:50 ``` # Suggested mitigation Two layers, in order of preference: (1) Reject `count == 0` in `virtio_snd_handle_pcm_info()` (and similarly in any sibling info handlers such as `virtio_snd_handle_chmap_info()` / `virtio_snd_handle_jack_info()` that follow the same g_new0(T, count) + iov_from_buf pattern). The driver-requirements text quoted in the source already says the buffer must be of size `sizeof(virtio_snd_hdr) + count*size`, so a zero-count request carries no useful payload and can be answered with the header alone (or rejected with VIRTIO_SND_S_BAD_MSG). (2) Defense-in-depth in `iov_from_buf_full()` / `iov_to_buf_full()` in util/iov.c: when `bytes == 0`, return early before entering the offset-skip loop, so callers passing a NULL buffer with length 0 do not trip the memcpy nonnull contract. This also covers other callers in the tree that may construct similar (NULL, 0) pairs from guest-controlled inputs. (1) is the targeted fix at the device layer; (2) is the generic hardening that prevents the same UB pattern from re-emerging in sibling devices. Please let me know if there is any context I missed.