I can trigger a host-side UndefinedBehaviorSanitizer shift-out-of-bounds report in current QEMU master through the AMD IOMMU command-buffer error path. The issue is in the AMDVI event encoding helper. `amdvi_encode_event()` encodes the 64-bit related-address field at bit offset 64: ```c static void amdvi_encode_event(uint64_t *evt, uint16_t devid, uint64_t addr, uint16_t info) { evt[0] = 0; evt[1] = 0; amdvi_setevent_bits(evt, devid, 0, 16); amdvi_setevent_bits(evt, info, 48, 16); amdvi_setevent_bits(evt, addr, 64, 64); } ``` The helper treats `start` as an absolute bit offset, computes the destination array index, but then passes the same absolute `start` value to `MAKE_64BIT_MASK()`: ```c static void amdvi_setevent_bits(uint64_t *buffer, uint64_t value, int start, int length) { int index = start / 64, bitpos = start % 64; uint64_t mask = MAKE_64BIT_MASK(start, length); buffer[index] &= ~mask; buffer[index] |= (value << bitpos) & mask; } ``` `MAKE_64BIT_MASK(64, 64)` expands to a left shift by 64: ```c #define MAKE_64BIT_MASK(shift, length) \ (((~0ULL) >> (64 - (length))) << (shift)) ``` Therefore any path that calls `amdvi_encode_event()` reaches undefined behavior when it tries to encode the related-address field. In the reproducer below, a guest-controlled illegal AMDVI command reaches `amdvi_log_illegalcom_error()`, which calls `amdvi_encode_event()`. This is independent of the separate AMDVI event-log-length issue: event logging is intentionally left disabled in the PoC. The sanitizer fires before `amdvi_log_event()` checks whether the event log is enabled. ## Environment I reproduced this on current master in the following environment: - host: x86_64 Linux - QEMU commit: `60533c6193ede6ce403e82d09d82ae2bc8fb423a` - build: `../configure --target-list=x86_64-softmmu --enable-ubsan --disable-werror` - machine: `q35` - device/configuration used for reproduction: `amd-iommu,dma-remap=on` ## Steps to reproduce Build a UBSan QEMU: ```text mkdir build-ubsan cd build-ubsan ../configure --target-list=x86_64-softmmu --enable-ubsan --disable-werror ninja -j$(nproc) qemu-system-x86_64 cd .. ``` Save the following as `repro_amdvi_event_encode_mask_shift_ub.sh`: ```sh #!/usr/bin/env bash set -euo pipefail QEMU=${QEMU:-./build-ubsan/qemu-system-x86_64} UBSAN_OPTIONS=${UBSAN_OPTIONS:-halt_on_error=1:print_stacktrace=1} \ timeout 5s "$QEMU" \ -display none \ -nodefaults \ -machine q35,accel=qtest \ -m 128M \ -device amd-iommu,dma-remap=on \ -qtest stdio <<'QTEST' # Put one illegal AMDVI command at guest physical 0x200000. The opcode in # cmd[1] bits 63:60 is 0xf, which takes the default illegal-command path. write 0x200000 0x10 0x00000000000000f00000000000000000 # Program a valid command buffer: base=0x200000, size exponent=1. writeq 0xfed80008 0x0100000000200000 # Enable AMDVI and the command buffer. Event logging is intentionally left # disabled: amdvi_log_illegalcom_error() encodes the event before checking # whether the event log is enabled, so this isolates the encoding bug from the # separate evtlog_len==0 error path. writeq 0xfed80018 0x0000000000001001 # Submit one command by advancing COMMAND_TAIL by one 16-byte command. writeq 0xfed82008 0x0000000000000010 clock_step 1000000 QTEST ``` Run: ```text chmod +x repro_amdvi_event_encode_mask_shift_ub.sh ./repro_amdvi_event_encode_mask_shift_ub.sh ``` ## Security boundary note The reproducer uses qtest only for deterministic MMIO and guest-memory setup. The affected path is the AMD IOMMU command-buffer/event-encoding path exposed to guests on an x86_64 `q35` virtualization machine when the AMD IOMMU is configured. This is not a qtest-only code path: a guest that can program the AMDVI command buffer can place an illegal command in guest memory and submit it through the emulated AMDVI MMIO interface. The immediate finding is host undefined behavior. With UBSan configured to halt on undefined behavior, this aborts the QEMU process. Without sanitizers, the practical impact should be triaged carefully: this PoC uses a guest-controlled illegal IOMMU command, so it may be treated as a robustness bug or self-inflicted guest DoS rather than a stronger isolation issue. It is still a real undefined-behavior bug in the host process and affects common AMDVI event-construction paths. ## UBSan output With a UBSan build this aborts the host process with: ```text hw/i386/amd_iommu.c:275:21: runtime error: shift exponent 64 is too large for 64-bit type 'long long unsigned int' #0 amdvi_setevent_bits hw/i386/amd_iommu.c:275 #1 amdvi_encode_event hw/i386/amd_iommu.c:293 #2 amdvi_log_illegalcom_error hw/i386/amd_iommu.c:349 #3 amdvi_cmdbuf_exec hw/i386/amd_iommu.c:1514 #4 amdvi_cmdbuf_run hw/i386/amd_iommu.c:1529 #5 memory_region_write_accessor system/memory.c:492 #6 access_with_adjusted_size system/memory.c:568 #7 memory_region_dispatch_write system/memory.c:1557 #8 flatview_write_continue_step system/physmem.c:3263 #9 flatview_write_continue system/physmem.c:3293 #10 flatview_write system/physmem.c:3324 #11 address_space_write system/physmem.c:3444 #12 qtest_process_command system/qtest.c:540 #13 qtest_process_inbuf system/qtest.c:824 ``` The triggering qtest output before the abort is: ```text OK OK OK ``` ## Suggested fix `amdvi_setevent_bits()` should not pass an absolute bit offset to a mask helper that expects a bit offset within a single 64-bit word. For the current AMDVI event layout, the simplest fix is probably to avoid the generic helper and encode the two 64-bit event words directly, for example: ```c static void amdvi_encode_event(uint64_t *evt, uint16_t devid, uint64_t addr, uint16_t info) { evt[0] = ((uint64_t)info << 48) | devid; evt[1] = addr; } ``` Alternatively, if the helper is kept, it should compute the mask relative to `bitpos`, handle `length == 64` without shifting by 64, and reject fields that would cross a 64-bit array element unless cross-word encoding is explicitly implemented.