## Disclosure: Automated Tool Usage This issue was discovered with assistance from AI/LLM-based analysis tooling. The finding has been manually validated and reproduced against unmodified upstream QEMU built from source. The PoC binary drives real, shipping QEMU code paths with no patches applied. --- ## Host environment - **Operating system:** Debian 12 (Docker build container) - **OS/kernel version:** Linux 6.x (tested on aarch64 host; bug is architecture-independent) - **Architecture:** Any (bug is in device model logic, not arch-specific) - **QEMU flavor:** `qemu-system-x86_64` - **QEMU version:** Built from source at commit `b83371668192a705b878e909c5ae9c1233cbd5fb` (post-v11.0.0, 2026-06-19) - **QEMU command line:** ``` qemu-system-x86_64 \ -machine q35 \ -display none \ -monitor none \ -serial stdio \ -no-reboot \ -device virtio-net-pci,netdev=n0 \ -netdev user,id=n0 \ -kernel poc_reentry.elf ``` **No patches applied. This runs against unmodified upstream QEMU.** ## Emulated/Virtualized environment - **Operating system:** Bare-metal i386 multiboot kernel (custom PoC guest, no OS) - **Architecture:** i386 (32-bit guest) --- ## Description of problem **virtio-net TX BH reentrancy guard uses wrong DeviceState — CVE-2024-3446 fix incomplete** The fix for CVE-2024-3446 introduced `virtio_bh_new_guarded()` to arm the **transport** (virtio-pci proxy) reentrancy guard during BH execution. This ensures that MMIO dispatch (which checks the transport's guard) correctly blocks reentrant access while a virtio BH is running. However, **virtio-net was never converted**. It still uses `qemu_bh_new_guarded()` with the virtio-net **device** guard: ```c /* hw/net/virtio-net.c, virtio_net_add_queue(), line ~2994 */ n->vqs[index].tx_bh = qemu_bh_new_guarded(virtio_net_tx_bh, &n->vqs[index], &DEVICE(vdev)->mem_reentrancy_guard); /* ^^^ WRONG: this is the virtio-net device guard, * not the virtio-pci transport guard */ ``` MMIO dispatch (`memory.c`, `access_with_adjusted_size()`) checks the **MemoryRegion owner's** guard — which is the virtio-pci transport device. Since the TX BH arms a different guard (the virtio-net device), the MMIO reentrancy block is never triggered. **Compare with the fixed devices** (same CVE-2024-3446 patch series): ```c /* hw/virtio/virtio-crypto.c — CORRECT: uses transport guard */ vcrypto->vqs[i].dataq_bh = virtio_bh_new_guarded(dev, virtio_crypto_dataq_bh, &vcrypto->vqs[i]); /* hw/char/virtio-serial-bus.c — CORRECT: uses transport guard */ port->bh = virtio_bh_new_guarded(dev, flush_queued_data_bh, port); ``` And the helper that resolves to the transport: ```c /* hw/virtio/virtio.c */ QEMUBH *virtio_bh_new_guarded_full(DeviceState *dev, QEMUBHFunc *cb, void *opaque, const char *name) { DeviceState *transport = qdev_get_parent_bus(dev)->parent; return qemu_bh_new_full(cb, opaque, name, &transport->mem_reentrancy_guard); } ``` virtio-net is the **only** virtio device with a BH that was not converted to `virtio_bh_new_guarded()`. It is also the most widely used virtual NIC. ### Impact A malicious guest can trigger reentrant MMIO access during TX BH execution by pointing TX descriptor buffers at the device's own MMIO BAR. When `virtqueue_pop()` → `dma_memory_map()` reads from this address, it re-enters the virtio-pci MMIO handler while `virtio_net_flush_tx()` is still on the call stack. This allows the guest to manipulate virtio device state (queue configuration, feature bits, device status) while the TX path holds live pointers to that state — enabling state corruption, potential double-frees, and control-flow hijacking via the same class of attacks that CVE-2024-3446 was designed to prevent. ### Additional unguarded entry points in virtio-net Beyond the TX BH, the following virtio-net paths also call `virtio_net_flush_tx()` without any reentrancy guard armed: 1. **Timer TX mode** (`tx=timer`): `virtio_net_tx_timer()` calls `flush_tx` with no guard at all 2. **Async TX completion**: `virtio_net_tx_complete()` re-enters `flush_tx` from a netdev callback 3. **RX path**: `qemu_new_nic()` registers with `&dev->mem_reentrancy_guard` (device guard, same mismatch) --- ## Steps to reproduce The attached `poc_reentry.c` is a bare-metal i386 multiboot guest kernel. Build and run as follows: ```bash # Minimal multiboot entry (boot.S): cat > boot.S << 'EOF' .set MB_MAGIC, 0x1BADB002 .set MB_FLAGS, 0x0 .set MB_CHK, -(MB_MAGIC + MB_FLAGS) .section .multiboot .align 4 .long MB_MAGIC .long MB_FLAGS .long MB_CHK .section .text .global _start _start: mov $stack_top, %esp call kmain 1: hlt jmp 1b .section .bss .align 16 stack_bottom: .skip 16384 stack_top: EOF # Linker script (link.ld): cat > link.ld << 'EOF' ENTRY(_start) SECTIONS { . = 1M; .text : { *(.multiboot) *(.text*) } .rodata : { *(.rodata*) } .data : { *(.data*) } .bss : { *(.bss*) *(COMMON) } } EOF # Build the guest: i686-linux-gnu-gcc -ffreestanding -nostdlib -m32 -O1 -c boot.S -o boot.o i686-linux-gnu-gcc -ffreestanding -nostdlib -m32 -O1 -c poc_reentry.c -o poc_reentry.o i686-linux-gnu-ld -T link.ld boot.o poc_reentry.o -o poc_reentry.elf # Run against unmodified upstream QEMU: qemu-system-x86_64 -machine q35 -display none -serial stdio \ -device virtio-net-pci,netdev=n0 -netdev user,id=n0 \ -kernel poc_reentry.elf ``` ### What the PoC does 1. Discovers `virtio-net-pci` via PCI bus enumeration 2. Initializes the device normally (feature negotiation, TX queue setup) 3. Submits a 2-descriptor TX chain: - `desc[0]`: valid virtio-net header in guest RAM - `desc[1]`: buffer address = **the device's own common-cfg MMIO BAR** 4. Kicks the TX queue When QEMU processes `desc[1]`, `dma_memory_map()` reads from the MMIO address, re-entering `virtio_pci_common_read()` while `virtio_net_flush_tx()` is on the call stack. ### Expected output (confirming bypass) The guest prints its PoC banner and completes TX processing. **No "Blocked re-entrant IO" message appears on QEMU stderr.** The absence of this message confirms the reentrancy guard is ineffective. ### Verification with fix applied Applying the one-line fix (see below) and re-running produces: ``` Blocked re-entrant IO on MemoryRegion: virtio-pci-common-virtio-net at addr: 0x... ``` This confirms that `virtio_bh_new_guarded()` correctly arms the transport guard and blocks the reentrant access. --- ## Suggested fix One-line change in `hw/net/virtio-net.c`, function `virtio_net_add_queue()`: ```diff - n->vqs[index].tx_bh = qemu_bh_new_guarded(virtio_net_tx_bh, &n->vqs[index], - &DEVICE(vdev)->mem_reentrancy_guard); + n->vqs[index].tx_bh = virtio_bh_new_guarded(DEVICE(vdev), + virtio_net_tx_bh, &n->vqs[index]); ``` Additional hardening (beyond the immediate fix): - Audit timer TX mode for reentrancy guard coverage - Audit `virtio_net_tx_complete()` callback path - Consider converting the RX NIC registration to use the transport guard as well --- ## Additional information ### Attached file - **`poc_reentry.c`** — bare-metal i386 guest PoC that triggers reentrancy on unmodified upstream QEMU. The multiboot entry (`boot.S`) and linker script (`link.ld`) needed to compile it are inlined in the reproduction steps above. ### Relationship to CVE-2024-3446 CVE-2024-3446 (CVSS 8.2) identified that `qemu_bh_new_guarded()` with the device guard does not protect against MMIO reentrancy because MMIO dispatch checks the transport guard. The fix introduced `virtio_bh_new_guarded()` and converted virtio-crypto and virtio-serial-bus. **virtio-net was not converted.** This submission reports the same vulnerability class in virtio-net — the most commonly deployed virtual NIC — which remains unprotected against the exact attack that CVE-2024-3446 addressed. ---